Cut Datadog Log Costs With Exclusion Filters and Log-Based Metrics

The problem: your access logs are pricing themselves out of usefulness

A high-traffic service can generate gigabytes of logs per day. In Datadog, logs that match your indexing rules count toward retained log usage, and that usage drives a large part of the bill. Health-check requests, internal service-to-service pings, and verbose debug output often make up most of the volume while contributing little to incident investigation.

The useful takeaway is to stop indexing the noise you do not need, and to turn the signals you do need into metrics. Datadog exclusion filters prevent matching logs from being indexed and counted toward usage. Log-based metrics then let you alert on error rates or traffic patterns without keeping every raw line for the full retention period.

Understand what counts as indexed log volume

Datadog counts a log toward your usage when it is ingested and indexed, not merely when it is sent to an agent. "Indexed" means the log is parsed, stored, and made searchable in Log Explorer for your retention period. Retention settings control how long those indexed logs remain available; shorter retention lowers storage cost but shortens the window for historical investigation.

Usage reporting breaks down indexed volume by service and source, which makes it possible to see which services are driving growth before you change anything.

Add an exclusion filter for noisy traffic

An exclusion filter tells Datadog to drop matching logs before they are indexed. Filters can be scoped by source, service, host, or tag, so you can exclude health-check traffic from one service while keeping security-critical logs from another.

Changes apply going forward only. Logs already indexed are not removed, and you do not get retroactive savings. Filter changes can also take several minutes to propagate across log pipelines.

Worked example: exclude successful health checks

Suppose you have a service called api-gateway that emits access logs. A load balancer hits /health every few seconds, and most of those requests return 200 OK. You want to keep failed health checks and all other API traffic, but stop indexing successful health-check logs.

In the Datadog UI, open Logs configuration and create an exclusion filter with a query similar to this:

source:nginx service:api-gateway path:/health @http.status_code:200

Replace source, service, and path with values that match your environment. The exact field names depend on your log integration and schema.

• Where to run: Datadog web UI, Logs configuration section.
• Permissions: Typically requires organization admin or a role with permission to manage log exclusions.
• Expected check: After the propagation delay, open Usage > Logs, group by service, and confirm that api-gateway indexed volume stops growing at the previous rate.
• Risk: An overly broad filter can drop logs you later need for debugging. Test on a non-production service first.

Replace retained logs with log-based metrics for key signals

If you exclude a noisy log source, you lose the ability to search those raw lines. Log-based metrics close part of that gap by converting matching log patterns into Datadog metrics. You can chart and alert on the metric without paying to retain every matching log.

For example, create a log-based metric that counts logs matching service:api-gateway @http.status_code:[500 TO 599]. The resulting metric can power a monitor for 5xx error rates even if you exclude individual successful requests.

Log-based metrics are derived from indexed logs, so they will not include events removed by exclusion filters or logs lost before ingestion.

Verify the metric appears

• Create the metric from a distinct log pattern in Logs configuration.
• Open Metrics Explorer and confirm the new metric appears within the expected processing delay.
• Use Usage > Logs grouped by service or source to verify that excluded sources no longer contribute to indexed volume growth.

Trade-offs and limitations

• Exclusion filters do not remove logs already indexed or produce retroactive cost savings.
• Log-based metrics miss excluded events, so they are not a complete replacement for raw log search.
• Pricing, ingestion limits, retention options, and feature availability vary by Datadog plan and contract. Confirm current terms before relying on cost estimates.
• Filter propagation can take several minutes, so immediate changes in Usage may not reflect the new filter.

Rollback

Because an exclusion filter changes logging state, you can undo it by disabling or deleting the filter in the same Logs configuration page. Matching logs resume indexing after the propagation delay, though any logs dropped while the filter was active are not recovered.

Start small and measure

Pick one non-production service with high log volume. Add an exclusion filter for a clearly noisy pattern, such as successful health checks, and watch Usage > Logs for a day or two. If the volume drops without losing signals you need, create a log-based metric for the errors you still want to track, then extend the approach to production services.