Datadog Pricing Explained (and How to Control It)

The first time a Datadog bill crosses five figures, someone in finance forwards it to engineering with a single question: what changed? The honest answer is usually nothing changed in how you monitor. What changed is that Datadog bills on a dozen different axes, and at least three of them scale with things nobody on the team is watching.

Here is how the pricing actually breaks down, product by product, and where the money quietly leaks out.

Infrastructure: per host, but hosts aren't the whole story

Infrastructure monitoring is billed per host per hour, rolled up monthly. A "host" is a physical or virtual machine running the agent. On the Pro tier you're paying roughly $15/host/month billed annually, more on-demand. So far so predictable.

The catch is containers. Each host includes a bucket of containers (Pro gives you 5 per host, Enterprise 10). Go over that bucket and you pay per additional container. In a Kubernetes world where a single node packs 40 pods, you blow through the included containers instantly, and now you're paying a per-container overage on top of the per-host fee. Teams running dense clusters often find container charges rival the host charges.

APM: the second host fee, plus spans

APM is billed per host again, separately from infrastructure. So an instrumented service host is billed twice: once for infra, once for APM. On top of that, newer plans meter ingested and indexed spans. You ingest everything the tracer emits, then you index (retain and make searchable) a subset. Indexed spans are where the searchable trace data lives, and they carry their own per-million charge. A chatty microservice mesh generates spans at a rate that surprises everyone the first time they look.

If you're still deciding which tracer to run, our roundup of APM tools is worth a read before you commit a budget to any one vendor.

Logs: ingest, index, retain, and the big surprise

Logs are where most runaway bills are born, because logs bill on three separate steps and people only budget for one.

• Ingest: every log line you send costs money to receive, priced per GB.
• Index: making a log searchable costs again, priced per million events, and it's tiered by retention. Fifteen-day retention costs more than seven-day.
• Retain/rehydrate: archived logs sitting in your own bucket are cheap, but pulling them back into Datadog to search them (rehydration) costs again.

The surprise is that ingest and index are decoupled. You can ingest a terabyte, index 5% of it, and only pay index rates on that slice. Most teams don't set this up, so they index everything by default and pay the full stack on debug-level noise from a health-check endpoint.

Custom metrics: the cardinality trap

Custom metrics are billed per metric, where "a metric" means a unique combination of metric name and tag values. This is the single most misunderstood line on the bill.

Emit orders.processed tagged with region (4 values) and status (3 values) and you have 12 custom metrics. Now someone adds a user_id tag. Suddenly every unique user is its own time series, and one metric name becomes hundreds of thousands. That's cardinality explosion, and it's how a well-meaning engineer adding a "helpful" tag turns a $200 line into a $9,000 one overnight.

RUM, Synthetics, Security

Real User Monitoring bills per 1,000 sessions, so a consumer app with heavy traffic scales with your users, not your infrastructure. Synthetics bills per test run: API tests per 10,000 runs, browser tests per 1,000, and a five-minute check schedule racks up runs fast. Security (Cloud SIEM, CSPM) layers on per-GB of analyzed logs or per-host again. Each is reasonable alone. Stacked, they're why the bill has thirty line items.

Why it scales unpredictably

Three things move independently of anything you consciously decide:

1. Container density rises every time you bin-pack a cluster tighter.
2. Cardinality rises every time anyone adds a tag, and nobody reviews tags in code review.
3. Log volume rises with traffic and with every logger.debug someone forgot to gate.

None of these show up in a planning meeting. They show up on the invoice.

The levers that actually work

• Exclusion and index filters on logs. Set filters so debug logs and health checks get ingested (cheap, archived) but never indexed (expensive). This alone routinely cuts log spend by half or more.
• Metric cardinality limits. Datadog lets you configure which tags are kept per metric. Drop high-cardinality tags like user_id, request_id, and raw pod_name. Watch the "top custom metrics by volume" page monthly.
• Sampling. Head-based or tail-based trace sampling means you keep the interesting spans (errors, slow requests) and drop the boring ones. You rarely need 100% of successful 200s.
• Agentless where it fits. Not every workload needs a full host agent. Cloud integrations and serverless can report without paying a per-host fee for ephemeral compute.
• Commit discounts. On-demand rates are punishing. An annual commit on your baseline usage cuts unit prices substantially. Commit to the floor, not the peak, and pay on-demand for spikes.

A worked example

A mid-size team runs 40 hosts, dense Kubernetes, full APM, and logs everything at 15-day retention. The bill:

• Infra: 40 hosts x $15 = $600, plus 900 overage containers ≈ $900
• APM: 25 APM hosts x $31 = $775, plus indexed spans ≈ $600
• Logs: 2 TB ingested, all indexed at 15 days ≈ $6,800
• Custom metrics: a user_id tag pushed them to 1.2M metrics ≈ $6,000

That's roughly $15,700/month. Now apply the levers. Index filters drop indexed logs to 8% and retention to 7 days: logs fall to about $1,400. Strip user_id and request_id from tags: custom metrics drop to 150K, about $750. Tail sampling at 20% halves indexed spans. An annual commit on the steady baseline shaves another 20% off unit rates. The new bill lands near $6,200, well under half, with zero loss of the signals anyone actually pages on. If you want the step-by-step version, we wrote up how to reduce Datadog costs in detail.

The call we'd make

Datadog is a genuinely good product priced to punish inattention. The tool won't stop you from indexing garbage or tagging by user ID; it'll happily bill you for it. So treat cost as an engineering concern, not a procurement one. Put a cardinality budget in your code review checklist. Default logs to ingest-not-index and make indexing an opt-in decision. Review the top-volume metrics and logs report once a month like you'd review error rates. Do that and Datadog stays worth its price. Skip it and the invoice will teach you the same lesson, just later and more expensively.