Exclusion Filter
An Exclusion Filter is a Datadog setting that drops logs matching a query from the index just before they enter a log index. Lowering the exclusion rate lets only a portion through, and the dropped logs still flow to Live Tail, archives, and metric generation.
Overview
An exclusion filter is a setting that uses a query and an exclusion rate to pick out logs that have passed the index filter and are heading into an index, and removes them from the index. Multiple filters can be lined up in a single index; they are matched from top to bottom, and only the first enabled filter that matches is processed. Excluded logs are removed from search and from monitors that use logs as their condition, but they still flow to Live Tail, serve as material for metric generation, and are sent to archives. You care about this when you want to lower indexing costs, and when you are tracking down why logs visible in Live Tail do not appear in the Log Explorer.
A setting that decides what to drop at the entrance to the index
An Exclusion Filter is a setting that drops logs matching a query from the index just before they enter a log index. By default there are no exclusion filters, and every log matching the index filter is indexed (as of September 2026; Source: Indexes). Once a log has been processed by a pipeline, the index filter first decides which index it heads to, and then that index's exclusion filters decide whether it is kept or dropped. The index filter decides "where to" and the exclusion filter decides "whether to let it in": two gates with different roles. A filter is configured with three items: a query that selects the target, an exclusion rate, and an enabled / disabled toggle. The details of the components and default values are left to the log index entry.
Top to bottom, and only the first match takes effect
When multiple exclusion filters are lined up in a single index, logs are matched from top to bottom, and only the first enabled filter that matches is processed. A matched log skips all of the subsequent filters, even when the exclusion rate's sampling draw puts it on the side that is kept (as of September 2026; Source: Indexes). The order can be rearranged in the list. The official documentation uses an example that lines up, in a single index, a 50% exclusion per request_id, preservation of threat tags, a DEBUG toggle, and a 90% exclusion of 2XX, and explains the results as follows.
| Incoming log | Result |
|---|---|
Logs that carry a request_id | Logs with the same request_id are kept together or dropped together (50% probability) |
Tagged threat:true or compliance:true | Kept regardless of request_id |
| DEBUG logs | Indexed consistently by following the request_id rule. Sampled separately only when the exclusion filter for DEBUG is enabled |
| 2XX web access logs | 50% are kept if they have a request_id. If not, they are sampled under the 90% exclusion rule |
What this example shows is that a rule placed higher up narrows the scope in which the rules below it apply. The basic ordering is "what you must keep at the top, what you drop broadly at the bottom"; if you put a broad condition at the top, the finer specifications below it never get a chance to apply.
Use the exclusion rate to choose between "drop everything" and "keep only a portion"
The exclusion rate can be set anywhere from 0% to 100%: at 100% every matching log is dropped, and below that the remainder is passed into the index (as of September 2026; Source: Indexes). The uses the official documentation gives fall into three patterns. The first keeps status:DEBUG at 100% exclusion and disables it with the toggle only during incidents or important releases so that DEBUG gets through. The second keeps all 3xx / 4xx / 5xx web access logs and excludes only 2xx at 95% with source:nginx AND http.status_code:[200 TO 299] to follow the trend. The third excludes env:production logs at 90% per value of @user.email, and for the users who remain, keeps their logs complete with no gaps. Because sampling can be done per attribute value, a design that keeps a gap-free full picture for just a subset of users holds up.
Dropped logs are not gone; they just do not enter the index
Exclusion is not deletion of logs. The official documentation states explicitly that excluded logs are discarded from the index but still flow to Live Tail, can be used to generate metrics, and are also sent to archives (as of September 2026; Source: Indexes).
- Logs processed by the pipelines arrive
- The index filter decides the destination index
- Logs that match an exclusion filter and are dropped by the sampling draw do not enter the index
- The dropped logs still flow to Live Tail, serve as material for log-based metrics, and are sent to archives
- Because they are not in the index, they are not covered by Log Explorer searches or by monitors that use logs as their condition
In practice, the last point is where you stumble. Logs that are visible in Live Tail but do not come up when you search the Log Explorer, or a monitor that counts logs and never fires, can sometimes be traced back to an exclusion filter. The official documentation states explicitly that monitors using logs as their condition evaluate only indexed logs (as of September 2026; Source: Log Monitor). Logs you turn out to need later can be brought back into the index by rehydration, provided you were sending them to a log archive. Even if you switch the toggle back to disabled, it only takes effect on logs that arrive from then on.
How it differs from retention filters and daily quotas
Take care not to confuse it with similarly named settings. An APM retention filter is a rule that selects which of the ingested spans to keep, while an exclusion filter is a setting that selects what to drop, so the direction is reversed. The daily quota, set on the same index, is an upper limit on the number of logs indexed per day: a mechanism that stops by volume without selecting by content. The relationship between the two is covered in the log index entry. There are two situations where you care about exclusion filters. The first is when you want to lower indexing costs, because the number dropped at the entrance translates directly into the indexed count. For how count-based billing works, see Making sense of Datadog log pricing. The second is when a log that should exist does not show up in search; make the list and order of exclusion filters in the Log Management settings screen your first place to check.