Log Index
A container that decides which of the collected logs are stored in a searchable state. Because retention in days and the daily limit are set per index, the Log Management bill is largely determined by how you design this.
Overview
A Log Index is a container that decides which of the logs sent to Datadog are stored in a form that can be searched and analyzed. The official documentation positions it as the mechanism that segments logs for retention period, daily quota, usage monitoring, and billing. The reason log costs are said to be hard to read is that there are two separate charges: one incurred by the volume sent and one incurred by the number of events put into an index. Once you can think of these two stages separately, you escape the crude binary of "store everything or keep nothing." When debug logs balloon overnight, whether you can keep investigating the cause without worrying about the next morning's bill is determined by how many indexes you prepared, which logs you put into which container, and where you set the daily limit.
Only logs that entered an index can be searched
Sending logs to Datadog does not mean everything you sent is searchable as is. The official documentation explains a Log Index as the mechanism that segments logs for retention period, daily quota, usage monitoring, and billing, and states that facet search, pattern display, analytics, and monitors are available for logs that entered an index. Conversely, logs that are not in an index are outside the scope of these features.
- The Agent or the API sends the log
- Ingestion: the stage billed by uncompressed data volume. Incurred regardless of whether the log is put into an index
- Index filter: evaluated from the top down; the log enters the first index whose conditions match
- Exclusion filter: thins logs out before they enter the index. Dropped logs still remain for Live Tail, metric generation, and archives
- Daily quota: the upper limit on the number of events stored that day. When reached, only indexing stops
- Indexing: billed as event count at a unit price by retention days; the log becomes searchable here for the first time
A new account starts with a single index that receives all logs. If you operate in this initial state, none of the three controls along the path (routing, thinning, and limit) is in effect, so the volume you send becomes the indexing volume as is. The first thing to check in a consultation about log cost is not the collection settings but how many indexes there are.
The more you split containers, the more predictable the budget, but the order decides the outcome
The official documentation recommends splitting indexes when you want to use multiple retention periods or hold multiple daily quotas. This is a split to avoid housing logs of different natures in one container, for example keeping audit-related logs longer and access logs used for operational checks shorter. The number of indexes is limited to 100 per account by default (as of August 2026) and can be raised by asking support. There are constraints on naming: the first character must be a letter, and only lowercase letters, digits, and hyphens can be used. Furthermore, a deleted index stops accepting logs, can no longer be searched, and its name can never be used again. This means you need to decide names on the assumption that they cannot be corrected later. What is easy to overlook in operation is order. Filters are evaluated from the top down, and a log enters the first index whose conditions match. Because reordering can be done with a drag operation, the act of inserting an index one position higher reassigns how many days those logs are stored and at which unit price they are billed. Some of the logs that used to go into an existing index move silently, so it is safest to check the change in counts before and after reordering. If you make services and environments identifiable with Tags, you can write these routing conditions concisely.
Reading the price table shows the variable that matters is not retention days
On the official pricing page as of August 2026 (us region, three tiers of annual / monthly / on-demand), ingestion is 0.10 USD per GB, and the scope is stated as processing and ingestion of uncompressed data, or scanning of compressed data during rehydration. Indexing is priced per million log events per month, with a unit price for each retention period.
| Retention period | Annual | Monthly | On-demand |
|---|---|---|---|
| 3 days | 1.06 | 1.27 | 1.59 |
| 7 days | 1.27 | 1.52 | 1.91 |
| 15 days | 1.70 | 2.04 | 2.55 |
| 30 days | 2.50 | 3.00 | 3.75 |
Prices for retention beyond 30 days are not published and are handled on inquiry. The prices in this article are examples at each point in time and do not reflect price changes made after writing. There is something to read from the shape of this table. Extending retention from 3 days to 30 days, that is, tenfold, raises the unit price by only about 2.4 times. On the other hand, switching the payment method to on-demand without changing the retention days makes the price 1.5 times the annual contract at 3-day retention. The number of days is a rather blunt variable for cost; squeezing retention does not bring the unit price down to one tenth, it only narrows the range you can search. In order of effectiveness: reduce the number of events put into an index, commit to your usage in advance, and then choose the retention days. The event count can be moved directly with exclusion filters and daily quotas, so those are what you touch first when you want to lower cost. If you start from a debate about retention days, you tend to end up cutting the period you can investigate while the bill barely changes.
Dropping before indexing - exclusion filters and daily quotas
An index has no exclusion filters by default. In other words, every log that matches the index filter conditions is indexed. Working on this is the main task in holding down cost. An exclusion filter consists of three parts: a query that selects the target, a sampling rule, and an enabled/disabled toggle. The defaults right after creation are a query of *, a rule of "exclude 100% of matching logs," and the enabled state. The sampling rate can be set from 0% to 100%, and there are two forms: targeting logs one at a time, and targeting groups by attribute value. For the grouping unit you can choose an attribute such as @user.email or the trace ID. In the one-at-a-time form, Datadog uses the trace ID for the decision when one is present, so whether logs belonging to the same trace are kept is consistent and the correlation with Traces is less likely to break. The pitfall is the early termination of evaluation. Only the first matching enabled filter is processed, and moreover a matching log skips the subsequent filters even when sampling kept it. If you place a filter that "drops 90% of debug logs" above and a filter that "drops everything from a specific service" below it, the lower specification does not reach the logs that matched the upper condition. The official documentation explicitly states that when you want to align rates across multiple indexes, you need to write the same sampling rate and the same attribute in each index's rule. Exclusion is not deletion. Excluded logs still stream in Live Tail, can be used to generate metrics, and are also sent to archives. This means you can set up "remove from search scope but keep tracking the trend in numbers," which is different in nature from a decision to delete logs. The other safeguard is the daily quota. You set an upper limit per index on the number of events stored per day in units of 1 million, and it applies to the volume after exclusion filters. When the limit is reached, indexing stops, but checking in Live Tail, sending to archives, and generating metrics continue. The reset time is 14:00 UTC every day by default (specification as of August 2026) and can be changed to any time. A warning threshold can be set as a percentage of the quota, and the value must be 50% or higher. Changes to the limit and the threshold take effect immediately, and an event is generated when the limit is reached, so you can route it to notifications with a monitor. With this mechanism, even if debug logs erupt in the middle of the night, the cost stops at the ceiling within the same day, and Live Tail and archives remain. Compared with a state where the only way to notice a budget accident is the invoice at the end of the month, this is the value of observation itself.
Things to confirm in the form of questions
Are logs removed from the index lost? They are not. As described in the previous section, Live Tail, metrics, and archives remain alive, so it can serve as a place for logs that "are unlikely to need searching later, but whose volume you want to measure." Does moving logs to archives make search cheaper? This needs to be considered separately. According to the pricing page as of August 2026, rehydration from archives is 0.10 USD per GB of compressed data scanned, and it is explicitly stated that the portion put back into an index is billed again at the contracted unit price of the chosen retention period. There is also Archive Search, which searches the archive directly without returning logs to an index, at 0.05 USD per GB scanned (annual contract) (Source: Rehydrating from Archives). An archive is a cheap place to store, but it is not a cheap search window. If an operation of bringing logs back for every investigation continues, putting them into a short-retention index from the start yields a simpler and more predictable cost. Can you calculate the indexing event count from GB per day? You cannot. There is no official conversion formula from GB to event count, and the guided method is to estimate by extending a query that counts log events over the last 24 hours to 30 days. If you build the basis of your estimate on "the size per event is probably about this much," you receive a bill that is off by an order of magnitude. Does reducing the number of indexes make it cheaper? The number of indexes itself is not billed. What moves is the number of indexed events and the retention days. Consolidating indexes means logs of different natures share the same retention days and the same limit, which tends to lead to paying for long retention for the sake of logs that only needed a short one. Also keep the distinction from similar mechanisms in mind. Retention is a value set per index, and a Log Index is the container that holds that setting. Custom Metrics and Cardinality are about metrics-side billing, a separate account from log indexing. The location of the configuration page and the primary source can be found at Log Indexes, unit prices on the Datadog pricing page, and the positioning within the overall product on the Log Management page.