Datadog Cost Optimization: 10 Ways to Cut Your Bill (2026)

Datadog's original pitch was infrastructure monitoring priced per host, so host count is still the metric that shows up on the account overview, gets reported to finance, and gets negotiated hardest at renewal. For a traditional fleet of long-lived VMs, that was a reasonable proxy for cost. It stopped being one once workloads moved to containers, autoscaling groups, Kubernetes nodes, serverless functions, and ephemeral CI runners — none of which map cleanly to "a host" — and once Datadog's own product surface expanded to roughly 20 separately metered SKUs covering infrastructure, APM, logs, RUM, synthetics, security, and more.

Observability and monitoring tooling has become one of the fastest-growing non-compute line items on a cloud bill, and broad industry benchmarking (Flexera's 2026 report) puts overall cloud waste at roughly 29%. A meaningful share of that waste hides specifically in observability spend, because unlike compute or storage, nobody reviews a "custom metrics" line item in a monthly infrastructure review — it doesn't correspond to a resource anyone owns. A host someone can right-size. A spike in custom metric cardinality from a code change three deploys ago is invisible until the invoice lands.

The fix starts with reading the bill by SKU instead of by host count. Once you can see which line items are growing independently of your infrastructure footprint, the rest of this guide is about closing each one down.

Most of a Datadog invoice comes from a handful of SKUs, not all 20. The table below lists illustrative 2026 list prices (annual commit, Pro-tier equivalents where applicable) for the ones that move real bills — treat every number as a placeholder for your own rate card.

Notice that the three SKUs behind the thesis of this article — indexed logs, APM/spans, and custom metrics — add up to roughly 60% of the illustrative bill above, well ahead of the infra host line most negotiations target. That's the pattern worth internalizing: hosts are the stable, boring part of the bill. The volatile part is almost always somewhere else.

Datadog doesn't bill custom metrics by metric name — it bills by unique timeseries, which means every distinct combination of a metric name and its tag values counts separately. A metric like checkout.latency tagged only by region might produce a handful of timeseries. The same metric tagged by user_id produces one timeseries per unique user who ever triggers it, and that count only grows as your user base grows.

This is the cardinality trap: a single line of code adding one high-cardinality tag to one metric can turn a five-dollar line item into a five-figure one, and it usually ships without anyone noticing until billing flags it weeks later. The worked example later in this article walks through exactly that scenario with real numbers.

Metrics Without Limits is Datadog's answer to this: it lets you ingest a metric with its full tag set for querying ad hoc, while choosing a smaller set of tags that actually get indexed and billed as separate timeseries. Applied correctly, a team can keep user_id-level detail available for a one-off investigation without paying to permanently index every user as a distinct billed series. The catch is that it has to be set up before the cardinality explosion happens, or applied as the fix once it's caught — it doesn't retroactively refund the metrics already billed that month.

Two habits prevent most cardinality incidents: never tag a custom metric with anything that scales with your user base or request volume (user IDs, request IDs, email addresses, raw IP addresses), and run a periodic audit of custom metrics against the dashboards and monitors that actually reference them — metrics nobody queries are pure waste regardless of their cardinality.

Datadog logs bill twice, and the two charges measure different things. Ingestioncharges for every log line you ship, regardless of what happens to it next. Indexingcharges separately, per event, for the subset you choose to make searchable and keep at a given retention window. Most teams default to indexing everything they ingest, which means they pay full price to make permanently searchable a mountain of health-check noise, verbose debug output, and duplicate log lines nobody will ever query.

Exclusion filters are the lever: they run at the point logs enter the pipeline and decide what gets indexed, without affecting ingestion. A filter that drops health-check 200s, known-noisy debug namespaces, and duplicate retry logs typically cuts the indexed share from close to 100% of ingest down to 15–25%, while ingestion cost (already the cheaper of the two charges) stays flat. For logs you're required to retain for compliance but rarely query, Flex Logs (or an equivalent low-cost archive tier) stores them searchably at a fraction of the indexed-log price, at the cost of slower query latency when you do need them.

Sampling is the complementary move for genuinely high-volume, low-value log streams — access logs on a high-traffic endpoint, for instance — where even exclusion from indexing doesn't make sense because the ingestion volume itself is the problem. Sampling a fixed percentage at the source (in the logging library or sidecar, before Datadog ever sees it) cuts both the ingest and index charges proportionally.

These same ingest/index economics show up on every major logging platform, not just Datadog — our guide to cutting logging costs across vendors covers the pattern in more detail if you're comparing Datadog against Splunk, Elastic, or CloudWatch Logs specifically.

APM pricing layers the same ingest/index pattern on top of a per-host APM charge. You pay a flat rate per APM-enabled host, then pay again for the volume of trace spans ingested, and again for whichever subset of spans you choose to retain at full fidelity for searching and analytics. The two levers that control this are sampling and retention filters, and they operate at different points in the pipeline.

Head-based (ingestion-time) sampling happens in the tracer, before a trace ever leaves your service. You decide up front — say, keep 10% of traces — and the decision is made without knowing whether that particular trace was interesting (a slow request, an error). It's simple, cuts ingestion volume (and therefore cost) at the source, but risks dropping the rare, high-value traces you most want to see.

Retention filters operate after ingestion: you ingest everything (or a high percentage), then apply rules that keep 100% of error traces and slow requests at full retention while sampling down the high-volume, uninteresting bulk — successful, fast, routine requests. This is closer to what's often called tail-based sampling in spirit: the decision about what to keep accounts for how the trace actually turned out. It costs more at the ingestion stage than head-based sampling, but avoids throwing away the traces most useful for debugging.

The practical approach for most teams is a blend: apply moderate head-based sampling to cut raw ingestion volume on very high-throughput services, then layer retention filters on top so errors and outliers are never sampled away before they can be flagged for full retention.

Roughly ordered from fastest payoff to longest-term structural change. Savings ranges are illustrative percentages of the relevant line item, not of the total bill — apply them to whichever SKU each lever targets.

1. Log exclusion filters on noisy sources. An hour of work on health-check, debug, and retry-log patterns. Savings: 30–70% of the indexed-logs line.
2. Metrics Without Limits + drop risky tags. Audit custom metrics for high-cardinality tags (user IDs, request IDs) and either exclude them from indexing or remove them outright. Savings: 20–90% of the custom-metrics line, depending on how bad the sprawl is.
3. APM ingestion sampling with error/slow-request retention filters. A half-day of tracer config. Savings: 40–80% of span ingestion and indexing cost.
4. Reduce RUM session sampling rate. Most products don't need 100% of sessions recorded to spot real UX regressions. Savings: directly proportional — sampling to 30% cuts the RUM line roughly 70%.
5. Delete unused custom metrics and dashboards. Cross-reference metrics against monitors and dashboards that actually query them. Savings: 10–30% of the custom-metrics line, with zero ongoing effort once done.
6. Move cold, rarely-queried logs to Flex Logs / archive tier. Keeps compliance retention intact at a fraction of the indexed price. Savings: 15–40% of the portion of indexed logs that's compliance-driven rather than operationally queried.
7. Right-size host count and remove orphaned agents. Decommissioned instances and duplicate container agents keep reporting long after the workload is gone. Savings: 5–15% of the infra-host line, with no ongoing maintenance.
8. Trim redundant synthetic tests and test frequency. Consolidate overlapping checks and reduce browser-test frequency on low-traffic paths. Savings: 20–50% of the synthetics line.
9. Right-size annual commitment tiers. Requires a few months of usage data. Savings: 10–30% versus on-demand, but only if the committed tier matches actual usage — see the commitment section below.
10. Consolidate overlapping observability tools. The longest-term move: if you're running Datadog alongside a second APM or logging tool out of habit or acquisition debt, picking one eliminates duplicate ingestion entirely. Savings: variable, but often the single largest number on this list once untangled.

Example 1: a 120-host startup with cardinality sprawl. Assumptions: 120 hosts on an infra Pro plan at an illustrative $15/host-month, each generating around 150 custom metrics on average (business and infrastructure metrics combined), with each host's plan including a free allowance of 100 custom metrics.

A developer debugging per-user latency adds a user_id tag to five checkout-flow metrics. With roughly 15,000 monthly active users, those five metrics stop being five timeseries each and become 15,000 timeseries each — 75,000 new series replacing the original five. Total custom metric count jumps from 18,000 to about 93,000, overage jumps from 6,000 to 81,000 billable series, and the custom-metrics line goes from $300/month to $4,050/month— a $3,750/month increase, roughly 13x, from one tag on five metrics.

The fix: apply Metrics Without Limits to exclude user_id from the indexed tag set (keeping it queryable only for ad hoc investigation, not permanently billed) and remove the tag once the debugging session is done. That restores the custom-metrics line to roughly its original $300–400/month, recovering the full $3,650–3,750/month delta.

Example 2: a log-heavy platform team. Assumptions: a platform team ingests roughly 5 billion log events per month across their services (about 2,500 GB at a typical ~500 bytes/event), and — like most teams starting out — indexes everything by default at 15-day retention.

Applying exclusion filters to drop health-check 200s, verbose debug namespaces, and duplicate retry logs from the indexed set — without reducing what's ingested, so nothing is lost for later re-indexing if needed — brings indexed volume down to roughly 1 billion events a month. The logs bill drops from $8,750/month to $1,950/month, a $6,800/month reduction, about 78%. Rebuild both examples with your own host count, metric tagging habits, and log volume — the mechanics transfer directly even when the raw numbers don't.

Datadog, like most usage-billed SaaS, prices annual commitments 10–30% below on-demand rates in exchange for committing to a minimum spend across a set of SKUs for the year. For a team with stable, well-understood usage, that discount is close to free money. For a team still finding its footing on custom metrics or log volume, it's a bet that can go either way.

Bursting past a committed tier bills the overage at the full on-demand rate, not the discounted committed rate — so a team that commits to a tier sized for average usage and then has a cardinality incident (see Example 1 above) pays on-demand pricing on top of the explosion, compounding the damage. Over-committing is the quieter version of the same mistake: paying up front for a usage tier the team never grows into wastes the unused allowance just as thoroughly as an overage wastes the on-demand premium, just less visibly, because it never shows up as a spike on an invoice.

The practical rule: don't commit to a tier until you have at least two or three months of stable usage data to size it against, build in headroom for growth you can actually forecast rather than growth you hope for, and revisit the commitment at renewal rather than letting it auto-renew at a tier set a year earlier under different usage patterns.

Not every team should optimize a Datadog bill — some should leave, and it's worth saying honestly when that's true rather than only ever selling the next lever.

CloudWatch makes sense if your workload is almost entirely AWS-native, your dashboards are simple, and you don't need cross-cloud or on-prem visibility — you give up Datadog's unified APM/logs/metrics correlation and its much better UI, but for an AWS-only shop with modest needs the savings can be substantial. Our breakdown of CloudWatch's own pricing covers its ingestion and custom-metrics charges, which follow a similar shape to Datadog's.

Self-hosted Grafana + Prometheus (plus Loki for logs) trades Datadog's subscription cost for infrastructure cost and operational ownership — you pay for the servers and the on-call burden of running your own observability stack, but at high enough volume the compute cost of self-hosting undercuts per-GB and per-metric SaaS pricing significantly. The trade is real: you lose Datadog's polish, its integrations, and the time your team would otherwise spend on product work.

An OpenTelemetry pipeline into cheaper storage (routing traces, metrics, and logs through an OTel collector into a lower-cost backend, keeping Datadog or another SaaS only for the subset of data that benefits from its analysis tools) is the middle path: you keep vendor flexibility and avoid being fully locked into one pricing model, at the cost of running and maintaining the collector pipeline yourself.

The honest trigger for considering any of these: when observability spend crosses roughly 10% of total infrastructure spend and keeps growing faster than the business, it's worth building the comparison rather than applying the tenth incremental lever to the SaaS bill. For most teams below that line, the levers above get you most of the way there without the migration cost.