Short answer
Your Datadog bill is usually too high because telemetry volume grows faster than governance. Logs, APM traces, custom metrics, Kubernetes containers, high-cardinality tags and long retention policies can all increase cost when nobody actively controls ingestion, indexing, sampling and ownership. The fix is not to cut observability blindly. The fix is to separate useful production visibility from telemetry noise, then optimize the cost drivers without weakening incident response.
Executive summary
Datadog can be highly valuable when teams govern what they ingest, index, retain and query. A unified view of infrastructure, applications, logs, traces, metrics and Kubernetes workloads is difficult to build and maintain internally.
The problem starts when adoption grows faster than operating discipline.
A platform team enables log collection. A few services turn on APM. Kubernetes expands. Developers add custom metrics. Teams create log indexes with default retention. Tags accumulate without ownership rules. Six months later, the CFO asks why the Datadog invoice grew faster than infrastructure spend — and engineering cannot answer with confidence.
The root cause is rarely “Datadog pricing” alone. It is usually the interaction between architecture, configuration and governance.
Datadog provides real control mechanisms: Usage Details, Usage Attribution, Estimated Usage Metrics, log indexes, retention policies, exclusion filters, Metrics without Limits™, APM ingestion controls, trace retention filters and Observability Pipelines. But a control lever that nobody owns does not reduce cost.
A serious Datadog cost optimization effort does three things:
- It identifies which teams, services and environments generate the bill.
- It separates critical diagnostic signals from low-value telemetry.
- It applies safe optimization levers without degrading incident response, SLOs, security investigations or compliance visibility.
For most teams, the safest optimization order is: attribution first, logs second, custom metrics third, APM ingestion and retention fourth, Kubernetes tag cardinality fifth, and renewal modeling last.
Definition: what is Datadog cost optimization?
Datadog cost optimization is the process of reducing unnecessary Datadog usage while preserving the production visibility required to operate systems safely.
In practice, it covers:
- log ingestion control,
- log indexing strategy,
- log retention design,
- APM ingestion sampling,
- trace retention filters,
- indexed span volume,
- custom metric cardinality,
- Kubernetes tag governance,
- usage attribution,
- cost dashboards by team, service and environment,
- renewal preparation.
The wrong question is: “What can we remove?”
The right question is: “Which telemetry is useful, who uses it, how long should it be retained, and what is the lowest-risk way to keep it available?”
Who this article is for
This article is for CTOs, VP Engineering, Heads of Platform, SRE Managers, FinOps Managers and Engineering Managers responsible for Datadog spend in Kubernetes, microservices or high-volume telemetry environments.
It is especially relevant if your organization spends hundreds of thousands per year on observability and needs to explain, reduce or govern that spend without damaging production operations.
This article is not for teams trying to remove Datadog entirely. It is for teams that want Datadog to remain useful, but better controlled.
Cost driver map: where the Datadog bill usually comes from
| Cost area | What drives it | What to inspect first |
|---|---|---|
| Infrastructure monitoring | Hosts, billing plan, high-water mark behavior | Host count, autoscaling, unused agents |
| Container monitoring | Container volume above included allowance | Kubernetes nodes, pods, ephemeral jobs |
| Logs ingestion | GB submitted to Datadog Logs | Noisy services, debug logs, access logs |
| Indexed logs | Indexed events and retention policy | Index filters, exclusion filters, retention |
| APM hosts | Hosts submitting traces | Which services are instrumented |
| Ingested spans | GB of spans ingested | High-throughput services, sampling |
| Indexed spans | Spans retained by filters | Retention filters, trace analytics dependencies |
| Custom metrics | Metric/tag/host combinations or contract-specific metric model | Metrics Summary, tag cardinality, contract SKU |
| Kubernetes tags | Pod/container/orchestrator labels | DD_CHECKS_TAG_CARDINALITY, DD_DOGSTATSD_TAG_CARDINALITY |
| Usage attribution | Missing ownership tags | team, service, env, business unit |
Datadog’s own documentation supports this cost-driver model: logs are billed separately for ingestion and indexed events, spans are separated into ingested and indexed spans, containers can become an additional billable unit depending on plan, and custom metrics depend on the applicable pricing model.
Why Datadog costs grow with Kubernetes and microservices
Kubernetes and microservices multiply observability volume by design.
A monolith may produce a bounded set of logs, metrics and traces. A Kubernetes platform produces telemetry across clusters, nodes, pods, containers, namespaces, deployments, replica sets, jobs, services, sidecars, ingress controllers, service meshes and application workloads.
Kubernetes observability relies on metrics, logs and traces to understand cluster health and application behavior. That visibility is necessary, but it creates more telemetry surfaces to govern.
Five cost accelerators appear repeatedly in Kubernetes environments.
Logs scale with everything
Traffic, deployments, retries, errors, debug verbosity, access logs and background jobs all push log volume up. Datadog bills ingested logs based on the total GB submitted to the Logs service, and indexed log events based on the number of events submitted for indexing at the selected retention policy.
APM scales with request volume
Traced hosts, services, requests and spans can all affect APM usage. Datadog’s APM billing documentation lists APM hosts, ingested spans and indexed spans as separate usage dimensions.
Custom metrics scale with cardinality or contract model
Under Datadog’s traditional custom metrics model, a custom metric is a unique combination of metric name, host ID and tags. However, Datadog also documents Metric Name pricing for organizations that opt into those SKUs. Any cost model should therefore start by checking the actual Datadog contract.
Tags amplify both visibility and cost
Tags are essential for ownership and troubleshooting, but uncontrolled high-cardinality tags create cost and query complexity. Datadog documents containerized tag cardinality settings: low, orchestrator and high, controlled by variables such as DD_CHECKS_TAG_CARDINALITY and DD_DOGSTATSD_TAG_CARDINALITY.
Ephemeral workloads blur accountability
Autoscaled workloads, short-lived pods and temporary jobs make usage harder to reason about. Without consistent team, service and env tags, the platform team sees the bill but cannot easily assign ownership.
What to check first if your Datadog bill is too high
If the Datadog bill is increasing quickly, do not start by cutting random telemetry. Start with attribution.
First, use Usage Details to identify month-to-date usage across Datadog products such as hosts, containers, custom metrics, APM hosts and logs. Datadog documents this view as the place to inspect usage by product category.
Second, configure Usage Attribution and Estimated Usage Metrics by tags such as team, env, service or business unit. Datadog documents by-tag Estimated Usage Metrics through the Usage Attribution configuration.
Third, rank cost drivers by product area: logs, indexed logs, APM, indexed spans, custom metrics, containers and non-production telemetry.
Only then should you optimize.
A useful Datadog cost review starts with this question: “Which team, service and environment generated this usage — and is that telemetry still worth keeping at this volume and retention?”
The 12 configuration mistakes that inflate Datadog costs
1. Collecting all logs and indexing too many of them
The mistake: Every application, infrastructure and Kubernetes log ships to Datadog, and too much of that stream is indexed.
Why it increases cost: Datadog separates ingested logs from indexed log events. Ingestion is based on GB submitted, while indexed log events are billed per million events according to the selected retention policy.
How to detect it: Review Usage Details, log usage by index, index-level volume, exclusion filters and top services by log volume.
What to optimize instead: Use exclusion filters for high-volume, low-value logs. Split logs into multiple indexes with different retention policies. Archive logs that must be kept but do not need to remain searchable in Datadog. Datadog explicitly recommends multiple indexes for different retention periods, daily quotas, usage monitoring and billing.
2. Keeping the same retention for every log category
The mistake: Security logs, production error logs, debug logs and routine access logs all use the same retention.
Why it increases cost: Long retention on high-volume, low-value logs increases indexed log cost without necessarily improving troubleshooting.
How to detect it: List every log index with its filter, retention period, daily volume and actual query activity.
What to optimize instead: Use value-based retention:
- short retention for noisy operational logs,
- medium retention for production application logs,
- longer retention only for compliance, audit or investigation use cases.
3. No log routing or preprocessing before Datadog
The mistake: Every log line travels directly from workloads to Datadog with no filtering, routing, redaction or enrichment before it leaves the environment.
Why it increases cost: Once noisy telemetry reaches Datadog, it can already contribute to ingestion volume.
How to detect it: Check whether filtering happens in the Agent, collector, Observability Pipeline, log pipeline or only at the index level.
What to optimize instead: Filter and route as close to the source as your architecture allows. Datadog Observability Pipelines can collect and process logs and metrics inside your infrastructure before routing the data to destinations.
4. Enabling APM everywhere with no sampling strategy
The mistake: APM is enabled service by service, but nobody reviews which services generate trace volume or whether sampling matches diagnostic value.
Why it increases cost: APM usage can involve APM hosts, ingested spans and indexed spans. Datadog’s APM billing documentation lists those as separate usage dimensions.
How to detect it: Review Trace Ingestion Control, ingestion reason breakdowns, service-level ingestion and estimated usage metrics for APM.
What to optimize instead: Start with high-throughput, low-diagnostic-value services. Adjust ingestion sampling carefully. Datadog states that trace metrics such as request count, error count and latency are calculated from 100% of application traffic regardless of trace ingestion sampling configuration.
5. Confusing trace ingestion controls with retention filters
The mistake: Teams reduce retention filters and assume they have reduced APM ingestion.
Why it increases cost: Datadog states that retention filters do not affect what traces are collected by the Agent and sent to Datadog. Retention filters control indexing; ingestion controls control ingestion.
How to detect it: Compare ingested span volume with indexed span volume. Review retention filters and ingestion settings separately.
What to optimize instead: Use ingestion controls for volume reduction and retention filters for searchability and Trace Explorer needs.
6. Indexing too many spans
The mistake: Teams ingest traces and index too many spans for too long.
Why it increases cost: Datadog charges indexed spans based on spans indexed by retention filters or legacy analyzed spans.
How to detect it: Review retention filters, indexed span volume by service and env, and trace analytics monitors that depend on indexed spans.
What to optimize instead: Keep errors, high-latency traces, business-critical flows and representative samples. Avoid indexing routine high-volume success paths unless they are actively used.
7. Creating custom metrics with uncontrolled tag cardinality
The mistake: Developers emit custom metrics with tags such as user ID, request ID, session ID, container ID, endpoint path, customer ID or other dynamic labels.
Why it increases cost: Under Datadog’s traditional custom metrics model, a custom metric is identified by metric name, host and tag values. Datadog also notes that distribution metrics can multiply custom metric volume.
How to detect it: Use Metrics Summary and Top Custom Metrics to inspect metric volume and tag combinations. Datadog documents Metrics Summary as a place to view reported metrics and search by metric name or tag.
What to optimize instead: Define an allowlist of queryable tags. Use Metrics without Limits™ to configure which tags remain queryable and drop nonessential tags from indexed custom metrics where appropriate.
8. Generating span-based metrics with high-cardinality attributes
The mistake: Teams create span-based metrics grouped by unbounded attributes.
Why it increases cost: Datadog documents that span-based metrics are considered custom metrics and billed accordingly. Datadog specifically warns against grouping by unbounded or extremely high-cardinality attributes such as timestamps, user IDs, request IDs or session IDs.
How to detect it: Review generated metrics from spans and traces. Flag group-by dimensions that are not stable operational attributes.
What to optimize instead: Group by bounded dimensions such as service, route, status, environment or team. Use logs and traces for forensic detail, not custom metrics with unbounded labels.
9. Using Kubernetes high-cardinality tags by default
The mistake: The platform collects detailed Kubernetes tags without deciding which level of cardinality is necessary.
Why it increases cost: Datadog warns that sending container tags for DogStatsD metrics may create more metrics — one per container instead of one per host — and may affect custom metrics billing.
How to detect it: Inspect DD_CHECKS_TAG_CARDINALITY and DD_DOGSTATSD_TAG_CARDINALITY. Check whether dashboards and monitors actually need pod-level or container-level dimensions.
What to optimize instead: Default to low-cardinality tags. Increase cardinality only for specific services, checks or troubleshooting workflows where the value is proven.
10. Missing unified service tagging
The mistake: Logs, metrics, traces and containers use inconsistent tags for the same service or environment.
Why it increases cost: Poor tagging breaks usage attribution and forces teams to retain more data because they do not trust their filters.
How to detect it: Check whether env, service and version are consistently applied across logs, metrics, traces and containers.
What to optimize instead: Implement Datadog unified service tagging. Datadog recommends using env, service and version to tie telemetry together across products.
11. Monitoring non-production like production
The mistake: Development, QA, staging and preview environments send the same telemetry as production, with the same retention and indexing rules.
Why it increases cost: Non-production telemetry can become a large part of the bill, especially on Kubernetes platforms with many temporary environments.
How to detect it: Break down logs, custom metrics, APM and containers by env.
What to optimize instead: Use lower retention, stricter sampling, narrower indexing and different log levels outside production. Keep enough visibility to protect release quality, but do not bill preview environments like incident-critical production systems.
12. Optimizing only at renewal time
The mistake: The company waits until the Datadog renewal is close, then tries to reduce usage quickly.
Why it increases cost: Datadog usage is shaped by instrumentation, Kubernetes architecture, tagging, retention and team habits. These are difficult to change safely under procurement pressure.
How to detect it: Look at what triggers cost reviews. If procurement triggers them and engineering governance does not, the organization is reactive.
What to optimize instead: Run monthly usage reviews, alert on unexpected spikes, track product-level usage and maintain a renewal scenario model. Datadog’s log management best practices include alerting on unexpected log traffic spikes and indexed log thresholds.
Decision table
| Cost driver | Symptom | Likely cause | Optimization lever | Risk if optimized badly |
|---|---|---|---|---|
| Logs ingestion | GB grows every month | Verbose logs, debug logs, retries | Agent filters, pipelines, routing | Losing forensic evidence |
| Indexed logs | Indexed events spike | Too many logs indexed | Exclusion filters, index strategy | Missing incident logs |
| Log retention | Storage/search cost grows | Same retention everywhere | Tiered retention | Compliance gaps |
| APM ingestion | High ingested span volume | No sampling strategy | Ingestion controls | Missing rare traces |
| Indexed spans | Trace analytics cost grows | Too many spans retained | Retention filters | Broken trace monitors |
| Custom metrics | Metric count explodes | High-cardinality tags | Metrics without Limits™ | Broken dashboards |
| Span metrics | Unexpected custom metric cost | Grouping by IDs or timestamps | Bounded attributes | Losing useful dimensions |
| Kubernetes containers | Container cost rises | Autoscaling, ephemeral jobs | Scope monitoring, attribution | Cluster blind spots |
| Tags | Cost cannot be explained | No tagging governance | env, service, version, team | Poor correlation |
| Non-prod telemetry | Staging is expensive | Same rules as production | Environment-specific policies | Lower release visibility |
What not to cut
Do not reduce Datadog costs by blindly disabling logs, APM or Kubernetes monitoring.
The goal is not less observability. The goal is better observability per dollar.
Keep the signals that help teams detect incidents, understand customer impact, diagnose regressions, investigate security events and validate production changes. Cut or downsample telemetry that is duplicated, never queried, too verbose, incorrectly tagged, retained too long or generated by non-critical environments.
A safe rule: optimize telemetry noise first, production visibility last.
Datadog cost optimization checklist
Use this checklist before making any cost reduction decision:
- Can we break down Datadog usage by
team,serviceandenv? - Which log indexes are growing fastest?
- Which indexes are rarely queried?
- Which logs are ingested but never useful during incidents?
- Which retention periods are based on actual need?
- Which services generate the most APM ingestion?
- Which retention filters index the most spans?
- Which custom metrics have the highest cardinality?
- Are any span-based metrics grouped by IDs, timestamps or sessions?
- Are Kubernetes tag cardinality settings still at the right level?
- Are non-production environments treated differently from production?
- Can we explain the bill to the CFO in product, team and service terms?
If the answer to several of these questions is “no,” the problem is governance, not only pricing.
When to use a Datadog cost calculator
Use a Datadog Cost Optimization Calculator when you need a first directional estimate of where the bill is going.
A calculator is useful when:
- you know approximate host, container and APM usage,
- you know ingested and indexed log volumes,
- you want to model retention changes,
- you want to estimate custom metric reduction scenarios,
- you need to explain options to a CFO or procurement team,
- you are preparing for a renewal.
A calculator does not tell you what is safe to change. It gives a directional model. The audit determines which changes are technically safe.
For teams comparing Datadog with other telemetry architectures, use an Observability Stack Cost Comparison Calculator. For Elastic or OpenSearch-heavy environments, use an Elasticsearch / OpenSearch Cost & License Calculator.
When a Datadog cost review makes sense
A Datadog cost review makes sense when:
- the Datadog bill is growing faster than infrastructure usage,
- Kubernetes or microservices adoption is expanding,
- a Datadog renewal is coming in the next 3 to 6 months,
- the CFO asks for a clear explanation of observability spend,
- internal SRE and platform teams are too busy,
- teams disagree on whether logs, APM or custom metrics should be optimized first,
- usage is not attributed by team, service or environment,
- Datadog is business-critical and aggressive cuts would be risky.
The best time to review Datadog cost is before renewal pressure starts.
A structured Observability Cost Audit gives engineering and finance the same view of the problem: what drives cost, what is safe to optimize, what should not be touched, and which changes need validation.
Who can help reduce Datadog costs?
A Datadog cost optimization consultant can help when internal teams understand Datadog technically but lack the time, neutrality or structured cost model to run a full review.
An independent Datadog consultant is useful for three reasons.
First, the review is vendor-neutral. It can ask whether each telemetry stream is useful, duplicated, over-retained, badly tagged or better routed elsewhere.
Second, it connects engineering configuration to financial impact. Most observability cost problems live between platform engineering, SRE, FinOps, procurement and application teams.
Third, it reduces risk. The objective is not to cut monitoring. The objective is to preserve production visibility while eliminating waste.
This is especially relevant for companies running Datadog alongside Elasticsearch, OpenSearch, Kubernetes, Logstash, OpenTelemetry or internal telemetry pipelines.
For a dedicated service page, see the Datadog Cost Optimization Consultant page.
What an independent Datadog cost audit includes
A serious Datadog cost audit should produce more than a list of generic recommendations.
A useful audit should include:
- a Datadog usage map by product,
- a cost-driver breakdown by logs, APM, metrics, containers and retention,
- usage attribution recommendations by
team,serviceandenv, - log index and retention review,
- APM ingestion and retention review,
- custom metric cardinality review,
- Kubernetes tag governance review,
- non-production telemetry review,
- risk-ranked optimization backlog,
- implementation plan for safe changes,
- renewal preparation summary for finance and procurement.
The outcome should be a prioritized action plan, not a vague “reduce logs” recommendation.
About the consultant / independent review
I provide independent Observability Cost & Architecture Audits for teams using Datadog, Elasticsearch, OpenSearch, Kubernetes and high-volume telemetry platforms.
The audit focuses on practical cost drivers: log ingestion, indexed logs, retention, APM sampling, indexed spans, custom metrics, Kubernetes telemetry, tagging governance, usage attribution and architecture-level trade-offs.
The output is a prioritized action plan showing where cost is generated, what can be optimized, what should not be touched, and which changes require engineering validation before rollout.
FAQ
Your Datadog bill is usually high because logs, APM, custom metrics, Kubernetes containers, tag cardinality and retention grow without enough governance. The biggest issue is rarely Datadog itself. It is uncontrolled ingestion, indexing, sampling, tagging and ownership.
Reduce Datadog costs by optimizing telemetry noise first. Use log filtering, index segmentation, retention policies, APM ingestion controls, trace retention filters, Metrics without Limits™, usage attribution and environment-specific rules. Do not blindly disable production logs or APM.
Datadog can become expensive for Kubernetes when container counts, ephemeral workloads, logs, APM traces, custom metrics and pod-level tags grow quickly. Kubernetes observability cost depends heavily on tagging, log volume, custom metrics, sampling and retention design.
The biggest Datadog cost drivers are usually logs ingestion, indexed logs, APM hosts, ingested spans, indexed spans, custom metrics, container monitoring, high-cardinality tags and long retention periods.
Start with attribution, then identify the largest low-risk waste area. In many environments, that means high-volume low-value logs, non-production telemetry or high-cardinality custom metrics. For APM, reduce ingestion and indexing carefully so incident response is not compromised.
Metrics without Limits™ can help reduce indexed custom metric volume by controlling which tags remain queryable. Datadog describes it as a way to configure tag allowlists or blocklists and drop nonessential tags from indexed custom metrics.
Trace sampling can reduce APM ingestion volume, but it must be designed carefully. Datadog provides ingestion controls, while retention filters control which spans are indexed. OpenTelemetry also distinguishes head sampling and tail sampling, with different trade-offs.
Hire a Datadog cost optimization consultant when the bill is growing quickly, renewal is approaching, Kubernetes usage is expanding, the CFO asks for a cost explanation, or internal SRE and platform teams do not have time to run a detailed review.