How to Reduce Your Datadog Bill: A Practical Guide (2026)

TL;DR

• Datadog’s pricing has three meters that all grow independently: infrastructure hosts ($15-27/host/month), Application Performance Monitoring — tracing (an additional $31-40/host, and it requires a paired infrastructure host), and logs (ingestion and indexing billed separately).
• The fastest bill growth usually isn’t host count — it’s custom metric cardinality. One metric with a bad tag can generate thousands of billed timeseries on its own.
• Four real levers, all configuration changes: fix high-cardinality tags, control histogram aggregations, decouple ingestion from indexing with Metrics Without Limits, and index only the logs/spans you actually search.
• None of this requires switching tools. These are settings inside Datadog itself.

Why the bill grows faster than your infrastructure

Datadog bills on three separate axes, and each one can grow independently of the others. Infrastructure Monitoring runs $15/host/month on an annual Pro plan, or $18-27/host/month without an annual commitment. Application Performance Monitoring (tracing) adds $31-40/host/month on top — and it can’t be bought standalone, every host running it needs a paired infrastructure host, so the real cost of adding tracing to a host is closer to $46/month combined, not just that line by itself. Logs are billed in two separate steps: ingestion (processing and archiving) runs about $0.10/GB, while indexing (making a log actually searchable) is billed separately and at a meaningfully higher rate.

The part that surprises most teams: none of these three meters track headcount or server count directly. You can add zero new hosts and still watch the bill climb, because the growth is coming from custom metrics — and those scale with how your application behaves, not with how many servers you run.

The four real cost levers

1. High-cardinality tags — the most common budget killer

A custom metric doesn’t cost one price. It costs one price per unique combination of tag values on that metric. If api.request.count carries a user_id tag with 1,000 distinct values, that’s 1,000 separately billed timeseries from a single metric definition. The same applies to request_id, session tokens, raw timestamps, or any tag that’s effectively unique per event.

The fix is straightforward: never tag a custom metric with something that’s unique per user or per request. Replace user_id with user_tier, replace a raw timestamp with a bucketed time window, replace a request ID with an endpoint name. Removing high-cardinality tags from the worst-offending metrics commonly cuts custom-metric spend 40-60% on its own, with no loss of the visibility teams actually use — nobody was querying “show me this one specific user_id” as a dashboard anyway.

2. Histograms quietly multiply themselves

A single histogram metric generates five separate billed metrics by default: average, count, median, max, and the 95th percentile. If you only ever look at the median and the max, you’re still paying for all five. Datadog’s Agent config (histogram_aggregates and histogram_percentiles in datadog.yaml) lets you drop the aggregations and percentiles nobody queries.

3. Decouple ingestion from indexing with Metrics Without Limits

Most teams think they have to choose between “collect this metric broadly” and “pay for every tag value.” Metrics Without Limits removes that trade-off: you can ingest a metric at full cardinality for aggregation, but only pay to index — make queryable — the specific tag values you actually filter or group by in practice. For most high-cardinality metrics, the tag values anyone actually queries are a small fraction of the total.

4. Index only the logs and spans you actually search

The same ingest-vs-index split that applies to metrics applies to logs and trace spans. Ingesting and archiving a log is cheap; indexing it (making it searchable in the UI) costs more. Most teams index everything by default because it’s the path of least resistance during setup, then never revisit it. Auditing what’s actually searched — and archiving the rest to cold storage instead of indexing it — is usually a bigger lever than most teams expect, precisely because it was never a deliberate decision in the first place.

A pattern we see constantly

The single most common finding when we audit a team’s Datadog usage isn’t idle hosts or over-provisioned tracing. It’s one metric with a bad tag. A request_id or user_id left on a custom metric — added once for debugging, never removed — can quietly account for a large share of the entire custom-metrics line on the bill, completely on its own. It’s almost never intentional. Someone needed it for a few hours during an incident eighteen months ago, and it’s been billing ever since.

Trade-offs and what we’d avoid

• Don’t index everything “just in case.” List what you actually search in the last 30 days, index that, archive the rest. You can always re-index from cold storage if you need something later.
• Don’t drop tracing purely to save money without checking the math. The infrastructure host is required either way — removing tracing alone doesn’t remove that baseline cost, so make sure the tracing line specifically is what’s driving the number before cutting it.
• Don’t jump straight to a platform migration. Switching to the Grafana stack is a legitimate option (see our Datadog vs Grafana comparison), but it’s a real project with its own operational cost. The configuration fixes above usually recover most of the achievable savings first, with none of the migration risk.
• Don’t fix cardinality once and consider it done. New metrics get shipped with new features, and old habits (a debug tag left on “temporarily”) come back. Treat this as a recurring check, not a one-time cleanup.

What to do next

Not sure whether Datadog or the Grafana stack is the right fit at all? See Datadog vs Grafana Stack — the platform decision, separate from this cost question.