Anatomy of a Datadog cost report

We ran a beta diagnostic against a real org — a workforce-scheduling SaaS company, mid-market, unremarkable Datadog footprint — and the report it produced is a good example of what this kind of tool should hand back. Not because every finding was dramatic (most weren't), but because the report's structure is the actual product: a top-line summary you can read in thirty seconds, a table you can act on, a list of what to do next, two honestly-drafted support tickets for the things it couldn't determine on its own, and an appendix that shows exactly where every number came from. Here's a walk through each section, in order.

1. The top-line summary

The report opened with the two facts that mattered most, stated plainly: total monthly spend went from $532.58 in February to $606.02 in May — roughly an 8% rise quarter-over-quarter — and within that, two specific things were flagged as worth attention: a ~24% jump in logs and SIEM ingestion in March, and a 234% spike in daily trace throughput starting April 9th. Everything else in the report supports those two headline findings. That's deliberate — a report that leads with fifteen equally-weighted line items is a report nobody reads past the first page.

2. The cost-change table

Underneath the summary sits a table with four columns: issue, cost change, since when, and suggested action. A few real rows from this run:

Issue	Cost change	Since	Suggested action
logs_ingested	+$0.90 (+23.7%)	Feb–Mar	Review log sources, add a retention filter, reduce volume or enable compression.
siem	+$2.70 (+23.7%)	Feb–Mar	Audit SIEM rules and data feeds, apply retention filters, cut noisy rules.
ingested_spans (daily throughput)	+234%	2026-04-09	Check recent deployments for extra instrumentation.

Every row here is small enough to act on in isolation. That's the point of the format: instead of one abstract "your bill is up," you get a short list of specific, independently-actionable line items, each with a date and a next step attached.

3. The "what to do next" list

Below the table, the report converts those rows into a numbered action list — audit the log sources driving the spike, tune Adaptive Sampling for APM traces, check what shipped around April 9th, remove a dead retention filter, validate a suspiciously-named custom metric, and schedule a follow-up review against next month's bill. Nothing on this list requires Datadog expertise to execute. That's intentional: the diagnosis is the hard part, and it's already done by the time you're reading this section.

4. When the tool doesn't know, it drafts a question instead of a guess

Two findings in this report were genuinely inconclusive, and the report handled both the same way — not by guessing, and not by silently dropping the finding, but by drafting the exact support-ticket text to send to Datadog:

"Can you confirm whether the APM Adaptive Sampling Target is set correctly? I wasn't able to match any retention filter to the known adaptive-sampling naming convention."

"For the custom metric 'couter,' tags could not be determined. Is this a typo, a missing tag, or a config issue that we need to correct?"

We cover both of these findings in depth in a separate post, because the pattern behind them is bigger than either individual finding: Datadog's own APIs don't expose a stable, documented way to programmatically confirm an Adaptive Sampling Target, and a metric with an ambiguous name is a metric nobody can confidently attribute cost to. Overclaiming a fix in either case — "your sampling target is X" or "this metric's missing tags are Y" — would have been a guess dressed up as a finding. A support-ticket draft is the honest output when the honest answer is "I don't know, and here's precisely what to ask."

5. Two findings that needed the exact date, not the monthly total

The ingested_spans line item's monthly cost actually fell 44% from March to April — but daily throughput inside that same April jumped 234% on one specific day. Those two facts look contradictory until you dig into why a monthly rollup can hide a single-day step-change entirely; we walk through that specific tension in its own post. Similarly, one retention filter in this org was sitting at 100% rate, matching precisely zero spans — the opposite failure mode from the "100% rate that's expensively over-retaining everything" pattern covered elsewhere on this site, and worth its own explanation, which we give here.

6. The raw-findings appendix

Every number in the summary above traces back to a computed input, listed in an appendix at the end of the report — monthly totals, month-over-month cost jumps, the exact turnover date and before/after throughput figures, the full retention-filter list, and a contract-analysis table. That last one is worth a mention on its own: this org had exactly $0.00 of committed coverage across all 40 findings analyzed — every product family fully on-demand, no volume discount anywhere, with infra_container_excl_agent alone accounting for $977.49 of on-demand spend over the five months analyzed. Nothing in the summary asserted that finding out of nowhere; it's sitting in the appendix, traceable, the same way every other number is.

That traceability is the actual design principle underneath all of this: a report that just tells you "here's what's wrong" is asking you to trust it. A report that shows you the computed inputs behind every claim is asking you to verify it — which is a much better position to be in when the number in question is your own invoice.

A later run against the same anonymized company took this appendix a step further: instead of separate, individually percent-sorted sections for cost jumps, forecasts, and on-demand exposure, it introduced a single "Top priorities" ranking that merges all three into one list, sorted by absolute dollar impact rather than percent change. We cover why that change matters in its own post.