Platform Engineering · AWS · Kubernetes
Your observability data and your cost data have never met.
When someone asks why infrastructure costs went up, your answer shouldn't be a spreadsheet and a best guess.
Trufflow gives you the connection between service behaviour and cost impact.
→ cost query \ --service payments-api \ --window 24h \ --show cost-per-request Connecting to observability pipeline... ok Connecting to AWS billing data... ok Resolving service → cost mapping... ERROR No connection between observability data and cost data. Cannot attribute cost to service behaviour. Trace context exists. Cost context: none. HINT Try manual investigation: 1. Open AWS Cost Explorer 2. Pull CUR export → query in Athena 3. Cross-reference Datadog manually 4. Build spreadsheet approximation 5. Present with low confidence Estimated time: 2–3 days → _
The data exists. The connection doesn't.
Did it actually save anything?
Every engineering discipline has a feedback loop. You deploy, you measure, you know if it worked.
Cost optimisation has been the exception — connecting observability data to billing data has meant spreadsheets, Athena queries, and best guesses.
Why your current stack can't answer the question
Every tool covers its layer.
None cover the gap between them.
The question “what does this service behaviour cost me right now?” sits in the space no existing tool was designed to occupy.
The gap between observability data (what your service is doing) and billing data (what it costs) is structural, not accidental. These tools were built for different questions. Trufflow is built for the one that lives between them.
The vision
Cost, where engineers
already look.
Not a new dashboard. Not a report. Cost as a native signal in the observability workflow you already live in — attached to every trace, attributed to every deploy.
Cost on every span
Open any trace in your existing observability tool. No new dashboard to open, no context switch.
trufflow.cost.total · trufflow.cost.vs_baselineDeploy-attributed savings
Every cost delta is attributed to the specific deploy that caused it. Optimization decisions are backed by evidence, not assumptions.
confirmed at deploy · not at month-endRegressions your alerts miss
Latency and error rates can stay flat while a deploy still drives up cost. Trufflow surfaces what your alerts miss.
invisible to performance monitoringNo new tools to learn
Trufflow is a hosted service that pulls from your CUR exports and enriches your OTel spans. No additional instrumentation required.
OpenTelemetry compatiblebatch.process is 63% of this request's cost. The refactor in v2.5 reduced it by 18% — confirmed at deploy time.batch.process is 63% of this request's cost. Reduced 18% by refactor in v2.5.
Works with your existing observability stack.
No new dashboards. No data pipeline.
How it fits in your stack
No agents. No sidecars.
No traffic interception.
Trufflow is a hosted service that reads from your OTel pipeline and your CUR exports.
Your existing data flow is unchanged. If Trufflow goes down, nothing else does.
Built for EKS on AWS.
Trufflow requires read-only access to your CUR exports and your OTel collector pipeline. No write access. No data leaves your AWS account.
Early access
Sign up for early access.
Drop your email. We'll reach out to understand your setup, share what we're building, and give you early access when we ship. No calls you didn't ask for. No updates you didn't want.