Explanation
Why the waste happens and who it affects.
At list prices, indexing a million 1 KB events for 15 days ($1.70) costs many times more than ingesting that gigabyte ($0.10). By default a log index has no exclusion filter, so every log that matches the index filter is indexed and billed per million events. Health checks, successful load balancer and web access logs, DEBUG output and chatty framework messages are indexed alongside the error and audit logs people actually search.
Much of this volume is only ever counted or charted, not searched. Excluded logs still flow through Live Tail, can still generate log-based metrics and are still sent to archives, so excluding or sampling them from indexes removes the indexing charge while keeping trends and a recoverable copy. Without index-level rules, indexed volume grows with every new service and log source.
Billing model
The pricing dimensions that drive this cost.
Ingestion and indexing are separate meters, so excluding a log from indexes removes the larger charge but not the ingestion charge.
- Log ingestion
- Billed per GB ingested or scanned ($0.10 per GB on the public pricing page)
- Standard Indexing
- Billed per million log events indexed, priced by the index retention period ($1.70 per million for 15-day retention billed annually, $2.55 on demand)
- Exclusion filter
- An index rule with a query and a 0 to 100% sampling rate; excluded logs are not indexed but still reach Live Tail, log-based metrics and archives
- Daily quota
- A per-index cap on logs indexed per day; after it is reached, further logs are not indexed
How to detect
4 checks to find it in your estate.
- Open each index on the Logs Indexes configuration page and flag indexes with no exclusion filters, especially a catch-all index filtered on *
- Chart datadog.estimated_usage.logs.ingested_events split by service, status and datadog_is_excluded to see which sources are indexed (datadog_is_excluded:false) and how much volume each contributes, or use the Log Management - Estimated Usage dashboard
- Use Log Patterns on high-volume services to find repetitive messages such as health checks, 2xx access logs and DEBUG output that are indexed in large numbers
- In Audit Trail, query @evt.name:"Log Management" @action:queried grouped by @asset.new_value.query.indexes to find indexes that are rarely or never queried
How to fix
5 ways to remove the waste.
- Add exclusion filters for low-value logs, for example a 100% exclusion on status:debug that can be toggled off during an incident, or on health check and 2xx access log patterns; add them directly from the Log Patterns side panel
- Sample instead of dropping where some visibility is needed: exclude 95% of 2xx access logs while keeping errors, or exclude a share of unique @user.email or trace ID values so the kept sample stays consistent across related logs
- Before excluding high-volume logs that feed dashboards, generate log-based metrics from them; these are billed as custom metrics, so avoid grouping by unbounded attributes such as request or user IDs
- Set a daily quota on each index with a warning threshold, and a monitor at 80% of the quota, so a new source or an accidental switch to debug logging cannot index unlimited volume
- Tradeoff: excluded logs cannot be searched in Datadog unless they are rehydrated from archives, and exclusion filters apply in order, so review filter order and confirm no monitor relies on the excluded logs
Documentation
Vendor references for pricing and configuration.