Datadog Logs Pricing:
How to Control Log Costs
Logs are often the largest and most unpredictable component of a Datadog bill. They are also the most controllable, once you understand the difference between ingestion, indexing and retention.
Why logs are often the biggest cost surprise
No other Datadog product scales with engineering activity as directly as logs do. Every deploy, every autoscale event and every new microservice adds log volume.
Most teams start Datadog with a simple setup: ship all logs, index everything, keep the defaults. That works fine at low scale. As services multiply and traffic grows, that default configuration becomes expensive fast. A Kubernetes cluster emitting standard container logs at scale, combined with an application outputting at INFO or DEBUG level, can generate log volumes that account for the majority of the total Datadog bill.
The surprise is not that logs cost money. It is that the volume is often dominated by events that no one is actively querying (verbose output from infrastructure components, health check responses, internal service-to-service calls) sent in full and retained at default periods because no one has had the conversation about what is actually needed.
Common log cost surprises
- A single Kubernetes cluster emitting container stdout/stderr at full verbosity
- Debug logging left enabled after a production incident, never turned off
- Load balancer and reverse proxy access logs retained at 15 days across all indexes
- A high-traffic endpoint emitting a log event for every request, including health checks from monitoring systems
- High-cardinality attributes in log events multiplying storage and indexing costs
Ingestion, indexing and retention: explained
Understanding these three concepts is the foundation of Datadog log cost governance. Most teams conflate them, which makes cost reduction harder than it needs to be.
Tier one
Ingestion
Sending a log event to Datadog. Every log you ship is ingested. Ingestion is metered by volume and is the entry point for all other cost. Logs that are ingested but not indexed can be forwarded to archive storage at significantly lower cost, making them available for rehydration if needed but not consuming indexing budget.
Tier two
Indexing
Making a log queryable in Log Explorer, available for alerting and monitored in dashboards. Indexing is substantially more expensive than ingestion alone. The decision about which logs to index (and which to ingest-and-archive rather than ingest-and-index) is the single most impactful cost lever available in the logs product.
Tier three
Retention
How long indexed logs are kept queryable. Longer retention means more stored events and higher cost. Default retention periods are often longer than any incident investigation actually requires. Tuning retention per index (shorter for high-volume operational logs, longer for security and compliance-critical sources) is a straightforward and permanent cost reduction.
Common causes of log cost growth
- Verbose application logs: applications logging at DEBUG or TRACE level in production, emitting multiple events per request for normal operations
- Noisy infrastructure logs: Kubernetes control plane, container runtime, kube-proxy and similar infrastructure components generating high volumes of operational events
- Kubernetes and container logs: stdout/stderr from all containers in all namespaces shipped without any filtering or exclusion policy
- Debug logs left enabled: debug verbosity enabled during an incident or deployment, never disabled once the investigation is complete
- High-cardinality log attributes: fields such as user_id, session_id or request_id on every log event increasing storage and indexing cost
- Long retention defaults: all indexes on the same retention period regardless of operational requirements or compliance obligations
- No exclusion policy: health check responses, readiness probe logs and similar high-frequency, zero-value events indexed at full fidelity
Cost-control techniques
These are the controls we apply when working with teams on Datadog log cost governance. All are platform-native, no external tooling required.
Exclude or sample noisy log sources
Datadog log exclusion filters let you drop events that match defined patterns before they consume indexing budget. Health check responses, readiness probes and verbose infrastructure events that no one queries are good candidates. Sampling applies a percentage rate to high-volume sources that would be useful occasionally but not in their entirety.
Route logs before ingest with Observability Pipelines
Datadog Observability Pipelines intercept log data before it reaches its destination and let you route, reduce and transform it. Low-value events can be sent to archive storage rather than indexed Datadog logs. Sensitive data can be redacted at the pipeline. Security logs can be routed to a separate destination with appropriate retention. Pre-ingest control prevents waste before it happens.
Use indexes intentionally
Rather than one index with everything, create indexes for distinct log types (application logs, infrastructure logs, security logs) with retention periods appropriate to each. This gives you granular control over what is queryable, for how long and at what cost. It also makes compliance audits simpler because security-relevant logs are in a clearly defined, appropriately retained index.
Tune retention per index
Review each index and ask honestly: how far back does any incident investigation actually go? How far back is compliance genuinely requiring? For operational logs, shorter retention is often entirely sufficient. For security and audit logs, a separate index with appropriate retention ensures you meet obligations without applying compliance-grade retention to everything.
Convert selected logs into metrics
Some logs contain numeric values (request duration, queue depth, error count) that are more cost-effective to store as metrics than as log events. Datadog log-based metrics let you extract those values from log events as they arrive and retain the time-series data indefinitely at metric cost, while applying shorter retention to the underlying log events.
Use Flex Logs for variable-retention needs
Datadog Flex Logs provides a tiered storage option for logs that need to be retained but are queried rarely. For high-volume sources where you want the data available without paying full indexed log retention rates, Flex Logs is worth reviewing as part of a retention rationalisation. It is particularly relevant for compliance-driven retention of sources that engineering teams query infrequently.
Full guide
Datadog pricing and cost optimisation
The complete guide: all cost drivers, the 5-step Observability FinOps framework, the full list of optimisation levers and the 30-day cost review plan.
Read the full guideRelated Datadog cost guides
Frequently asked questions
Why are Datadog logs so expensive?
Datadog log costs grow when ingestion volume is high and retention is long. The most common causes are Kubernetes and container log floods (verbose infrastructure logs that ship in enormous volumes) and default retention settings applied to all indexes without review. Logs from debug-level output, health checks and internal service calls add volume without adding operational value.
What is the difference between log ingestion and log indexing in Datadog?
Ingestion is the act of sending a log event to Datadog. Indexing is the act of making it queryable in Log Explorer and available for alerting. All indexed logs are ingested, but not all ingested logs need to be indexed. Logs can be ingested and sent to archive storage without being indexed, which is significantly cheaper. The decision about which logs to index, and for how long, is one of the most impactful cost controls available.
How do I reduce Datadog log retention costs?
Review each log index and ask what retention period is genuinely needed for operational and compliance purposes. Many teams find that default retention is longer than any incident investigation actually requires. Setting shorter retention on high-volume, lower-value indexes and longer retention only on security and compliance-critical indexes can substantially reduce cost without losing the coverage that matters.
What are Datadog Observability Pipelines and how do they reduce log costs?
Datadog Observability Pipelines let you route, filter and transform log data before it reaches its destination. For cost control, this means dropping noisy events before they consume indexing budget, routing low-value logs to cheaper archive storage and redacting sensitive data at the pipeline layer rather than ingesting it in full.
Book a Datadog log cost review
We will audit your log indexes, retention settings and ingestion sources and show you exactly where the cost is coming from, and what to do about it.