Retention

Overview

Retention is the period that expresses how long data sent to Datadog is stored and available for search and on-screen display. Where many people stumble here is that Datadog has no single setting called "retention." The official documentation defines a default retention period per target data, and 15-month items and 2-hour items sit side by side within the same product family. It means that the kinds of data you still have on hand differ depending on whether you review an incident the next day or 3 weeks later. Furthermore, for logs and spans, the contract plan and index settings take effect, so the places to check are split between the UI and the contract. This entry organizes the defaults per target and the alternative means to consider before extending retention, from official information as of August 2026.

Retention is not a single number

The question "how long does Datadog data remain" cannot be answered with a single number. The data retention periods list in the official documentation takes the form of rows per product and target data, each with its own default. Metric tags and values are 15 months, container metadata is 2 hours, and information on running processes and containers is 36 hours. Even data visible on the same screen is not guaranteed to still be there tomorrow. The official glossary also has no standalone entry for "retention." Instead it lists the APM "retention filter," explained as a mechanism synonymous with indexing, a rule that decides what to keep for 15 days. In other words, retention in Datadog is not a standalone setting item, but is determined as the result of combining the default per target data with the index and contract settings. If you operate without knowing this structure, you will find out in the form of not having the data you need when you need it. When you start investigating on Monday a performance degradation that occurred on Friday night, the values on the graphs remain, but the list of processes that were running at that time can no longer be viewed. Conversely, if you know the defaults per target, you can set up an operation such as "this kind of data will be gone by the next business day, so on the same day, keep it in a monitor notification or a note rather than a screenshot." Understanding retention directly determines the success or failure of post-incident investigation.

Common sayings versus the actual defaults

Let us pair the phrases you hear in the field with the official descriptions. "Datadog data remains for 15 months." This is a description of metric tags and values, not of everything. Targets to which the same 15 months apply include Event Management, Cloud SIEM signals, Cloud Cost Management cost metrics, and Synthetics test results, but each of these is an individually defined value. "Logs remain for the same number of days as everything else." In the official list, the retention period for Log Management is stated as "determined by the customer's plan." In practice, since the retention days are set per Log Index, 3-day and 30-day ones coexist within the same account. To answer "how many days do we have" for logs, you need to look at the list of indexes. "Traces remain for 15 days." APM indexed spans are described as 15 or 30 days depending on the plan. Meanwhile, APM errors are 15 days, service and resource statistics are 30 days, and a trace once opened in the UI is stored for as long as the account exists. Since the values differ by target even within APM, whether a trace still remains gets a different answer depending on which view you search from. "Session Replay disappears after 30 days." The default is 30 days, but it is stated as 15 months when using the extended option in the UI. This is an example where the presence or absence of an option changes it by nearly 15 times. Lining these up shows that what you should memorize is not the individual numbers of days themselves. What you should remember are 2 points: the structure that it differs per target, and that for logs and spans the contract and settings take effect.

Before extending, line up the alternatives

When you feel that retention is not enough, the first thing that comes to mind is extending the number of days. However, that is not necessarily the most cost-effective choice. Let us go through them in order. The first to consider is the path of converting logs into numbers and keeping them long term. The official docs state explicitly that logs excluded from the search target by an index exclusion filter can still be used to generate metrics. If "we only want to see the trend of error occurrence counts a year from now," there is no need to store the log text for long. Once you turn the count into a metric, it can be handled with the retention on the metric side. Another path is archives. But do not get the premise wrong. According to the pricing page as of August 2026, Archive Search, which searches archives directly without restoring them to an index, starts at 0.05 USD per GB scanned, and anything rehydrated from there back into an index is billed again at the contract unit price of the selected retention period (Source: Rehydrating from Archives). Archives are a means of long-term storage, not a means of searching cheaply. It fits a once-a-year audit response, but if your operation restores them every time for a weekly investigation, holding an index with a short retention is cheaper. One more path is Flex Logs. The pricing page as of August 2026 states that it starts at 0.05 USD per month per 1 million stored events (annual contract), retention can be selected from 1 month to 15 months, and a minimum of 30 days is billed. Note that this unit price is for storage, and there is separate billing for the compute resources (Flex Compute) used to search and aggregate in Flex Logs. Since no public unit price is shown on the pricing page as of August 2026, confirm with a quote when adopting it. This is a tier designed as the place for logs you want to keep long term but search infrequently. The prices in this entry are examples at each point in time and do not reflect price revisions after writing. And the choice of extending the number of days also has procedural constraints. The retention periods selectable for an index are only the values permitted in that account's configuration. If you want to use a retention period not included in your contract, according to the official documentation you must contact Datadog Customer Success, and in addition an administrator must enable the relevant item in the organization settings. That is, it is not a setting you can extend on a whim on the day of an incident. Designing retention belongs to the work you finish before an accident happens. Thinking in this order shifts the axis of judgment from "how many days to keep" to "at what granularity to keep." Keep the full text as is, keep only the numbers, or compress it and let it rest. The very fact that the design lets you choose the granularity is the reason you can follow long-term trends without letting costs balloon without a ceiling.

Defaults per target, and distinguishing neighboring concepts

The following is an extract of the default retention periods stated in the official documentation as of August 2026, selecting those most frequently used in design decisions. Rows that change with the contract plan or options are marked as such.

There are also targets stored for as long as the account exists, such as dashboards, notebooks, monitor definitions, incidents, and reference tables. The organizing principle is that what disappears is observed data, not what you configured. Finally, let us separate the confusing words. Retention is a period value: "how long to keep." A Log Index is the container that serves as the unit for setting that value, and each destination to which logs are routed can have a different period. The APM retention filter is not a setting that decides a period but a rule that selects "which spans to keep in the index," and the official glossary treats it as synonymous with indexing. If you confuse this rule, which takes spans as its target, with the period itself, you will misidentify where to cut costs. The primary sources are the Datadog official documentation Data Retention Periods, the index-side settings in Log Indexes, and the unit prices on the Datadog pricing page. The product-side explanations can be found on the Log Management and APM pages.