Flex Logs

Flex Logs is the long-term retention tier of Datadog Log Management that separates log storage (Storage) from the computing resources for search (Compute) and lets you choose each independently. Storage is determined by the number of logs, and search speed by the one Compute size you select for the organization.

Overview

Flex Logs is a tier for keeping Datadog logs longer and more cheaply than Standard Indexing. Whereas Standard Indexing provides storage and search as a single package, in Flex Logs you decide the number of logs to store and the computing resources used for search (Compute) separately. It is a concept you care about when handling audit logs or network logs that you rarely look back at but must keep for a long time, and if you build indexes without knowing how to choose the Compute size and the constraint that they cannot be used with monitors, you will get the design wrong.

A tier where you choose how much to store and how much search power separately

Flex Logs is the tier within Datadog Log Management for keeping logs for a long time. In Standard Indexing for a log index, storage and search capability come as one, and extending the number of days retained raises the unit price accordingly. Flex Logs unties this link: Storage is determined by the number of logs retained, and search (Compute) by the size of the computing resources chosen for the organization, each decided separately. The official documentation explains that decoupling the cost of storage from the cost of compute makes it possible to offer long-term retention cheaply (as of September 2026; Source: Flex Logs). With this separation, the decision to extend retention and the decision of how much to pay for search speed can be made independently.

Five Compute sizes, one per organization

Compute is the computing resource used only when searching logs in the Flex Logs tier; it is not used for ingestion or for searches that target Standard Indexing alone. There are five sizes: Starter, Extra small (XS), Small (S), Medium (M), and Large (L). Each step up roughly doubles the search performance and capacity of the previous one, and the substance of a size is the upper limit on the number of queries that can run concurrently and the number of logs that a single query can scan (as of September 2026; Source: Flex Logs). The biggest factor in deciding the size is the number of logs accumulated in the Flex tier, and the official documentation gives cumulative guidelines as follows.

Guidelines for Compute size by cumulative number of logs stored
Compute sizeCumulative number of logs stored in the Flex tier
StarterUnder 10 billion
Extra small (XS)10 billion to 50 billion
Small (S)50 billion to 200 billion
Medium (M)200 billion to 500 billion
Large (L)500 billion to 1 trillion
Source: the Determine the compute size that you need section of Flex Logs (as of September 2026)

Only one Compute size can be in use at a time in a single organization; you cannot combine Starter with a scalable size, nor share one across multiple organizations. On US3, US5, AP1, AP2, US1-FED, and US2-FED, the three sizes available are Starter, XS, and S (all as of September 2026).

Three constraints on enabling and disabling

Enabling and disabling Flex Logs is done per organization and requires the flex_logs_config_write permission (as of September 2026; Source: Flex Logs). Flex Logs Starter alone can be enabled self-serve even if it is not in your contract. The entry point is the Flex Logs Control page, where you choose the Compute Type and size and click Enable Flex Logs. There are three constraints on going back. Sizes from XS up can be raised at any time, but can be lowered only once every 15 days. Changing your contract from Starter to a scalable size is not reflected automatically; you have to reselect the size on the same page and Save. To disable Flex Logs itself, you first remove Flex Storage from every index, and only then choose Disable Flex Logs from the gear icon. The order is such that you cannot disable it while any index still has a Flex tier.

How to tell which logs may go straight to Flex

Which logs to place in Flex Logs is judged by three things: whether the volume is high, whether they are rarely looked back at, and whether they need to be kept for a long time. The official documentation calls log sources that fit this description candidates for the Flex tier, and lists by type examples that may be sent directly to the Flex tier without going through Standard Indexing (as of September 2026; Source: Flex Logs).

Examples the official documentation gives as candidates for sending directly to the Flex tier
TypeExamples
Audit logsKubernetes audit logs / Microsoft 365 audit logs
CDNCloudFront / Fastly / Cloudflare
Load balancersAWS ELB / ALB / NLB / NGINX
NetworkAmazon VPC Flow Logs / WAF
CI/CDGitHub Actions / Jenkins / Argo CD
Source: excerpted from the Potential sources for sending directly to Flex Logs section of Flex Logs (as of September 2026)

On the other hand, for logs used in incident response and alerting, such as application logs, the guidance is to place them in Standard Indexing first and then extend the period after that with Flex. As for storage billing, Flex Storage is a monthly amount per 1 million events stored, and the computing resources for search (Compute size) are billed as a separate SKU (Source: Datadog Pricing). This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page. How to compare the billing units of the three tiers and how to choose a tier are left to the three tiers of log pricing.

What is cheap is storage; what is slow is Compute congestion

There are three points that are easy to misread about Flex Logs. The first is monitors. Logs in the Flex tier are not covered by monitors or Watchdog, and the logs of an index that has had the Standard Tier removed and is Flex Tier only disappear from monitors and Watchdog Insights. The second is the search toggle: in the Log Explorer, Flex tier logs are included in the results only when Include Flex Logs is enabled. The third is the cause of slowness. When the number of concurrently running queries reaches the Compute limit, queries retry repeatedly until a slot opens up and become slow. After retrying many times they fail, and an error reading Flex Logs compute capacity is constrained appears (all as of September 2026; Source: Flex Logs). The basic rule is to isolate slow searches as Compute congestion, not storage volume.

Share