The Datadog Bill, Decoded

What is indexed repetition?

The term is deliberate. “Volume” is what the invoice shows. “Repetition” is what the volume is made of. Datadog’s pricing pages, the FinOps dashboards, and most cost-reduction advice treat volume as the unit: send fewer GB, index fewer events, drop more tags. That framing leads to the wrong tools, because the tools that cut volume by rule (exclusion filters, sampling, tag drops) have to guess which volume is safe to lose, and the guess is made once, at configuration time, about data that hasn’t arrived yet. Repetition is different. You don’t have to guess whether the thirty-thousandth copy of a line matters. It doesn’t. The first copy, its count, and its time range are the record. The other 29,999 are the bill.

Two people read this guide for different reasons. The engineering manager or FinOps owner wants the number: how much of the indexed volume is repetition, in the invoice’s own units. The platform engineer who configures the Datadog Agent wants to know what changes in their pipeline and what doesn’t. The answer to the second question is the reason the first is worth asking: nothing in the Agent changes, and Datadog stays exactly where it is.

What am I actually billed for?

Datadog bills each signal on two axes, ingestion and indexing, and bills custom metrics on a third that has nothing to do with traffic: the count of distinct tag combinations. Misreading the split is the most common cause of a surprise invoice, and the same shape repeats across logs, APM, and metrics, so it is worth being precise about it once.

Two rows deserve a closer look. The first is custom metrics, because it is the only line that doesn’t follow traffic. Ingest and index grow roughly with request volume. Series count grows with the product of attribute values, so one engineer adding pod_name to a metric during a rolling deploy can multiply the series count by the number of pods that existed that day, and the invoice arrives a month later with no deploy to point at. The bill is the visible damage. The invisible damage is dashboards that time out during exactly the incident the metric was meant to explain, which is the cardinality explosion incident in Datadog’s clothing.

The second is log indexing, because it is where most of the surprise lives. Datadog separated ingestion from indexing so you could ingest everything cheaply and index selectively. In practice, exclusion filters are written once against yesterday’s noise, so today’s new noise (a new service, a new debug line, a new retry storm) sails through and gets indexed at the full rate. The Why did my Datadog log bill spike? card walks the diagnosis; the short version is that log bills almost never creep. They jump, and the jump is a pattern.

Put the three lines side by side and the shape is the same. A retry storm is thirty thousand indexed log events and one fact. A healthy checkout path traced ten thousand times a minute is ten thousand indexed spans and one shape. A metric split by request ID is a million series and one number per second. In every case Datadog is charging index prices for repetition, and in every case the native lever for that line item works by asking you to predict, in advance, which repetition you won’t need.

Where does each Datadog line item go wrong, and where does the native fix stop?

Each of Datadog’s three meters has a failure pattern, a native lever that addresses it, and a ceiling the lever can’t get past. The ceiling is the same each time: the lever needs you to know in advance what won’t matter. What follows is the four-part structure from the Guide to Controlling Datadog Costs, rewritten around that ceiling.

Custom metrics: one tag makes a metric explode

In Datadog, a custom metric is not a name. It is a name times every combination of tag values that has ever reported. api.request.count with env (3 values), region (6), and status (5) is 90 series. Add user_id and it is 90 times your active-user count. Each series is billed monthly over the allotment your hosts include, and each one has to be scanned when someone opens the dashboard.

What the native lever does. Metrics without Limits separates the tags you ingest from the tags you can query. Tags you don’t allowlist for querying don’t count toward indexed series. It is the right first move for any metric that has grown a volatile tag, and it costs nothing but the dashboards that were using that tag.

Where it stops. It is a per-metric allowlist, so someone has to know which metric exploded and which tag did it. Datadog’s custom-metrics governance pages help you find the top offenders after the fact. They can’t tell you that a tag added in today’s deploy is about to become tomorrow’s top offender, and the dimension you drop is usually the one that would have answered “which tenant” during the next incident. The Why are my Datadog custom metrics so expensive? card has the arithmetic; the high-cardinality post has the log side of the same problem.

APM: you’re indexing the traces that were fine

Datadog APM ingests every span and indexes the subset your retention filters match, plus an intelligent-retention slice. The default posture on most accounts indexes a broad sample of routine, healthy traffic, because that is the safe setting when you don’t yet know what you’ll need. Meanwhile head-based sampling at the tracer, which decides before the request finishes, is dropping traces before anyone knows they contain an error.

What the native lever does. Retention filters let you keep every error, every trace over a latency threshold, and a percentage of the rest. That converts a broad index into a targeted one and cuts the indexed-span line accordingly.

Where it stops. Retention filters are policies, and policies describe the failures you’ve already classified. The trace that succeeded in 400ms three minutes before the same code path started failing didn’t match a policy, so it’s gone, and it was the one that showed what normal looked like. Tail-based sampling in a collector improves on head-based by deciding after the trace completes, and it is still a policy. The Indexed vs. ingested spans card covers the mechanics.

Logs: ingest is cheap, index is where the money goes, and two teams are indexing the same lines

Logs are the largest and least controlled source of Datadog spend because every line can carry dynamic fields (request IDs, session tokens, payload fragments), because volume jumps rather than creeps, and because the security team is often duplicating the same stream into a SIEM. Same logs, indexed twice, paid for twice.

What the native lever does. Exclusion filters stop matched logs from being indexed (they are still ingested). Per-index daily quotas cap the damage from a spike. Archives send everything to S3 where it can be rehydrated into Log Explorer for a bounded window when you need it. Archiving is the one reduction in this guide that is reversible, and you should be doing it regardless.

Where it stops. Exclusion filters are written against noise you’ve already seen. The retry storm from a service that shipped this morning matches no filter and gets indexed at full rate until someone notices the usage graph. And a filter that excludes a whole service or severity is also excluding the INFO line that says something slightly different from yesterday’s INFO lines, which is where new failures first appear. The log bill spike card is the 30-minute diagnosis; the SIEM double-pay is a routing problem a collector solves in front of both destinations.

AI-SRE tools: garbage in, garbage out, at index prices

The fourth pillar isn’t a line item. It’s what the other three do to the tools you’re pointing at the data. AI-SRE and AIOps systems, Datadog’s own included, are only as good as the telemetry they read. Feed them thirty thousand copies of a retry line and they spend their context on the copies. Feed them a metric with a million series and root cause is a needle in a haystack you paid to build. The same repetition that inflates the bill degrades the answer.

Where the native levers stop. There isn’t one for this. Reducing volume by rule makes the haystack smaller but doesn’t change its composition; it is still raw records, still mostly copies. What an agent needs is the distilled form: the pattern, its count, its baseline, and what’s new against it. That is the input Möbius works from, and it is why the cost fix and the AI-readiness fix turn out to be the same step.

How do you send Datadog less without deciding in advance what to drop?

You send Datadog less by collapsing repetition before it reaches the index instead of selecting records by rule: read the actual content of every log line (its sentiment, its pattern, whether it’s anomalous, and its severity), group identical patterns into one entry with a count, baseline each service against itself, and flag what’s new against that baseline. That is content-based reduction rather than rule-based reduction, and it removes indexed repetition without anyone having to name it first. We call it Telemetry Distillation. (Not model distillation, which compresses a machine-learning model; this compresses the telemetry.) The OpenTelemetry Signal Loss guide makes the case from the collector side. This is the same method seen from the invoice.

Telemetry Distillation is a different kind of reduction for four reasons that matter to the bill.

It reads the content, not the metadata. Every native lever keys on something outside the message: a tag name, a severity level, a status code, a percentage. Continuous Telemetry Distillation reads the actual content of every log line, not just its status code, and scores it on four things: sentiment (a line that reads like a failure is treated as one, whatever level someone gave it), pattern (has this shape been seen before, and how often), anomaly (is it unusual for this service), and severity (the level, weighed against the other three rather than trusted alone). Signal and noise are separated by what the record says, which is the only place the distinction lives. It’s also why an INFO line that says something new survives while a thousand ERROR lines that say the same thing collapse to one.

It collapses, it doesn’t select. Thirty thousand identical retry lines become one pattern with a count of thirty thousand and a time range. Nothing is sampled. Nothing is filtered. Every record is read. The reduction is in repetition, not in coverage, which is what lets it produce a number Datadog’s usage pages can’t: the share of your indexed log volume that was copies.

It’s baselined per service. What is noise in checkout-api is not noise in auth-service. An exclusion filter is written once and applies everywhere. A baseline is learned per stream and moves with the service, so the new pattern in a quiet service is loud and the routine pattern in a loud service is quiet.

It sits beside Datadog, not in front of it. This is the property that makes the rest safe to try. The Agent keeps shipping to Datadog. Distillation reads the same sources a second time. Nothing in the existing path changes, so the governance conversation is “can a second reader see staging’s logs,” not “can we re-plumb production observability.”

What if you only run the Datadog Agent?

You don’t need a collector, and you don’t need to touch the Agent, because Telemetry Distillation doesn’t read from the Agent. It reads from the same places the Agent reads. Dstl8 calls each of those a source, and for a Datadog team the relevant ones are below, in the order of least to most installed. The honest constraint first: there is no way to tap the Agent’s own transport to Datadog. A second reader reads the sources, not the Agent.

Three things to notice about the first four rows. The Agent’s configuration is not part of any of them. Each is a same-day setup: a source goes from Pending to Healthy within minutes of the first logs arriving, and streams are detected and named by what emitted them (a Lambda function, a Deployment, a DaemonSet). And a second reader costs a second read: on Kubernetes that’s two tailers on the same files and a little CPU per node, on CloudWatch it’s read API calls against the log groups. On staging, or on one production account, that’s fine, and it’s the price of not touching the Agent.

Start with one source on staging, or the one AWS account whose Log Management line you understand best. The output is a per-stream repetition share that maps to that account’s indexed events. When you later want a single place to route from, the last row is the same collector tier the Signal Loss guide describes, and by then you know which streams are worth routing.

If you already run a collector

For the fourth row, the whole change is one exporter beside the one you have:

exporters:
  datadog:
    api:
      key: ${env:DD_API_KEY}                   # your existing Datadog exporter, unchanged
  otlphttp/dstl8:
    endpoint: https://<org_id>.app.dstl8.ai/src-<id>
    headers:
      Authorization: "Bearer <your-token>"

service:
  pipelines:
    logs:
      receivers: [otlp, filelog]
      processors: [k8sattributes, batch]
      exporters: [datadog, otlphttp/dstl8]     # add dstl8, keep Datadog

Datadog receives exactly what it received before. Dstl8 receives a copy. If you want to see the patterns before any exporter is added, dstl8 tap runs the same distillation against a local stream, and Gonzo shows them in a terminal with nothing leaving the machine.

Should you leave Datadog?

No, or at least not because of the bill. Here is the part most cost-reduction content skips: the vendors ranking for “reduce Datadog costs” mostly want you to replace it, and replacing an observability platform is a year of work that trades a known bill for an unknown one. You chose Datadog for reasons that haven’t changed. The dashboards, the alerts, the muscle memory of the on-call rotation are worth more than the delta on the invoice. Keep it.

Also keep the native levers, and turn them on before you talk to anyone, us included. Metrics without Limits on any metric that grew a volatile tag. Exclusion filters for health checks and load-balancer noise. Retention filters that keep errors and slow traces. Archives to S3 for everything, because rehydration is the only reversible decision in this guide. A team that has done those four things has usually cut the bill meaningfully, and the guide so far tells you exactly where each one stops.

What this guide argues against is narrower: treating those levers as the whole answer, because each one works by predicting which data won’t matter, and the data they’re worst at predicting is the repetition that makes up most of the index. Severity-based exclusions. Dropping the tag that identifies the tenant. Broad probabilistic retention. Those are the rules that save the most money and lose the most signal, and they are the ones Telemetry Distillation replaces, by collapsing the copies instead of guessing which ones are safe to drop.

The practical posture: keep Datadog, keep the levers you can defend as requirements, remove the ones you wrote to hit a number, and let content-based reduction hit the number instead. Then measure it, on staging, so “this much of our indexed log volume is repetition” is a figure in your invoice’s units and not a vendor’s claim.

What to change in Datadog once you have the number

Nothing, at first. Run both for a week on one source and let the pattern list tell you where the repetition is. Then work down this list, in order of how easily each step reverses.

Exclusion filters, written from the pattern list. The top repeated patterns that carry no information (health checks, retry chatter, startup noise) become exclusion filters on the index they land in. Still ingested, no longer indexed, so it moves the expensive line. Fully reversible in the Datadog UI. Before excluding anything, check which log-based monitors and dashboards query that index; excluded logs don’t feed them.

Archive-only for streams nobody queries. For the debug and INFO streams where the distilled patterns are now the surface people actually read, route them ingest → archive with no index. Rehydration keeps them recoverable for a bounded window. This is the S3 tiering the eBook described, done with Datadog’s own feature.

Per-index daily quotas as the backstop. A new pattern won’t match an old exclusion filter. A quota caps the damage from the next spike until someone writes the filter, and the distilled stream is where you’ll see the new pattern first.

Only after the collector tier: stop sending. Once a collector sits in the Agent’s path, streams that have moved to archive-only can stop going to Datadog at all, which also moves the ingest line, and the SIEM copy can be routed from the same place, which ends the double-pay. This is the step that changes the Agent’s configuration, so it is last.

Don’t touch: the error and warning indexes on-call depends on, anything a monitor references, and retention required for compliance. And since Dstl8 distills logs today, custom metrics and APM stay entirely on Datadog’s native levers from the pillars above.

Where do you go when you’re looking at one of these line items right now?

Every line item and every lever in this guide has a working page behind it: the arithmetic, the configuration, and the failure modes we’ve hit. In the order you’d actually read them.

Cardinality

Datadog and the collector

Reducing what you send, and what it costs

The method, from the other side

References

1. Datadog, Custom metrics billing: billable series as distinct tag combinations, per-host allotments, and overage.
2. Datadog, Metrics without Limits: separating ingested tags from queryable tags.
3. Datadog, Log Management billing, Indexes and exclusion filters, and Archives.
4. Datadog, APM billing and the trace pipeline: ingested vs. indexed spans and retention filters.
5. The New Stack, Datadog’s $65M bill and why developers should care.
6. ControlTheory, A Guide to Controlling Datadog Costs (eBook): the four-pillar structure this guide rewrites, and the “80% of spend from 7% of data” observation.
7. ControlTheory, The Engineer’s Guide to OpenTelemetry Signal Loss: the reduction toolkit table and the Telemetry Distillation definition.

Frequently asked questions