The Three Tiers of Datadog Log Pricing - Ingest / Index / Flex
Datadog log pricing has a three-tier structure: ingestion (Ingest) is counted in GB, indexing (Index) by event count and retention days, and long-term storage (Flex Logs) by stored event count. This article covers the billing unit and contract forms of each tier, the procedure for converting GB to event counts, and the two-stage cost structure of rehydration, then presents a decision table for choosing a tier from retention days and search frequency. For specific unit prices, it points to the official pricing page.
Log pricing is counted in three tiers
The answer to the question "are logs priced by GB or by count?" is "it depends on the tier." Datadog log pricing is split into three tiers, ingestion (Ingest), indexing (Standard Indexing), and long-term storage (Flex Logs), and each is counted in a different unit. On the official pricing page as of August 2026 (US region), the structure is as follows.
| Tier | Unit counted | Contract forms | Main caution | What it affects |
|---|---|---|---|---|
| Ingest | Uncompressed GB / month | Three forms, annual / monthly / on-demand (no unit price difference between forms for this tier) | Charged even if not indexed | The volume you sent, as such |
| Standard Indexing | Million events / month × retention days (3 / 7 / 15 / 30 days) | Unit price differs across the three forms, and rises with longer retention | Retention beyond 30 days has no published price | How many events are searchable, and how many days back you can search |
| Flex Logs Storage | Million stored events / month (retention 1 to 15 months, minimum 30 days) | Unit price differs across the three forms | Flex Compute for search is a separate SKU (not covered in this article; check the official pricing page) | How many events you keep for the long term. Search requires separately chosen compute resources |
| Flex Logs Starter | Million stored events / month (retention 3 / 6 / 12 / 15 months) | Unit price differs across the three forms (storage and search compute bundled) | Described as intended for organizations under 2 billion events per month | Small-scale long-term storage held at a single unit price |
The table runs from top to bottom in the order "volume sent → volume searchable → volume kept long-term." Because the variable that drives the bill differs by tier, "lowering log costs" also means different levers per tier. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
Why is ingestion in GB while indexing is in events?
Ingestion is the stage in which Datadog receives and processes logs, so it is counted by the volume passing through (uncompressed GB). Indexing, on the other hand, is the stage of keeping logs in a searchable state, and since the essence of the cost is how many days each log is kept, it is counted by event count × retention days. The official pricing page FAQ also explains that per-event billing is designed to encourage content-rich logs (as of August 2026; source: Datadog Pricing). The bill is finalized at month end. According to the official billing documentation, Datadog calculates the total number of indexed events at month end; if it is at or below the committed volume the bill is unchanged, and only the excess is added at the on-demand unit price (a premium over the contracted price) (as of September 2026; source: Log Management Billing). Because the commitment is monthly, a spike on a single day does not become overage if the monthly average is close to the committed volume, which is operational leeway. The basics of two-stage billing and index design are left to Log Management and log index; this article concentrates on counting and calculation.
What Flex Logs makes cheaper, and what it cannot do
Flex Logs is a tier that separates storage (Storage) from the compute resources for search (Compute). The official documentation divides log placement into three homes (as of September 2026; source: Flex Logs).
- Standard Indexing = logs searched frequently and kept short-term (example: application logs)
- Flex Logs = logs kept long and occasionally searched in a hurry (example: security / transaction / network logs)
- Archives = logs rarely searched and stored long-term (example: audit logs / configuration logs)
- Order when combined = to Flex after the Standard period ends (example: Standard 3 days + Flex 90 days means 87 days' worth in Flex)
Storage-only Flex Logs Storage is published at a unit price far lower than Standard Indexing, which keeps logs in a searchable state, and this gap in unit price is the basis for the decision "if you keep logs long, change tiers" (actual amounts on the official pricing page). Search compute is chosen from five sizes, Starter / XS / S / M / L, with the rule of thumb being Starter for under 10 billion cumulative stored events and XS for 10 to 50 billion. The constraints are also clear. Logs in Flex Logs are not covered by monitors or Watchdog, though dashboards can be used. Retention is 3 / 6 / 12 / 15 months for Starter and 30 to 450 days for XS and above, and in an index combined with Standard, logs move to Flex after the Standard period ends.
The official procedure for converting GB to event counts
There is no official conversion formula for "how many events is 10 GB of logs per day?" That is because the size of one event varies greatly with the type of log. The one procedure the pricing page FAQ gives is to count the last 24 hours with a count query and multiply by 30 to estimate the monthly event count (as of August 2026; source: Datadog Pricing). The count can be checked in three places: the Indexed Logs graph on the Usage screen, the index configuration screen, and the top of the list in Log Explorer (as of September 2026; source: Log Management Billing). Before you have measurements, state an explicit assumption such as "1 event = 1 KB, 1 GB = 1 million KB." Under this assumption, 10 GB per day is 10 million events per day, or 300 million events per month (300 in units of a million events). Multiplying this count by each tier's unit price is the skeleton of the estimate, and do not forget that if you change the assumption, the result moves with it.
Rehydration is paid twice - scanning and re-indexing
Rehydration is the operation of bringing logs back from an archive, and its cost arises in two stages. The first stage is a charge per compressed GB scanned, to which the same unit price as ingestion (Ingest) applies (pricing page as of August 2026; no difference by contract form). The second stage is the indexing of the events brought back, to which the contracted index unit price for the chosen retention period applies separately (source: Datadog Pricing). Because filtering is applied after the files are retrieved, the scan volume is determined by "the entire archive for that period," and even if you filter with service:A, logs from other services are read too (as of September 2026; source: Rehydrating from Archives). Narrowing the time range is the most effective way to hold down scan costs. A single historical view can bring back up to 1 billion events, and administrators can configure the event count cap and the retention period options. Index exclusion filters are not applied, so logs dropped at the time can also be brought back.
How is it determined for your configuration? - A decision table for choosing a tier
Written as a formula, the monthly cost is "ingested GB × Ingest unit price + indexed million events × Index unit price by retention days + Flex stored million events × Flex unit price." Flex storage volume is counted as the steady state with the retention period's worth accumulated, and search compute (Flex Compute) is added separately. What goes into each term of the formula is determined by which tier you place logs in, and that placement is almost entirely determined by two axes: "how many days back do you search" and "how often do you search."
| Days you go back | Search frequency | Suitable tier | Variable that moves the cost |
|---|---|---|---|
| Within 30 days | Frequent (everyday investigation) | Standard Indexing. Choose retention from 3 / 7 / 15 / 30 days by the number of days you actually go back | Indexing rate (the proportion of ingested logs indexed) and retention days |
| Within 30 days | Rare (only during incidents) | Narrow the indexing rate; the rest is ingestion only + archives | Ingested GB. Indexing cost falls in proportion to how much you narrow |
| Beyond 30 days | Occasionally, in a hurry | Flex Logs (Starter if the cumulative count is small, XS or above if large) | Steady-state stored event count and the Flex Compute size |
| Beyond 30 days | Almost never | Archives (rehydrate when needed) | Frequency of bringing logs back × scanned GB + re-indexed event count |
Three things can be read from this. First, in a configuration that indexes everything in Standard, the indexing term is the main player in the bill and ingestion is a supporting player. Second, if you set the indexing rate to 30%, the indexing term becomes exactly 30%, so the decision to keep logs you do not use in everyday investigation out of the index has a larger effect than the decision to shorten retention days. Third, a requirement to keep audit logs for 12 months is, given that Standard beyond 30 days has no published price, correctly framed from the outset as a Flex Logs question (Starter or XS and above). The answer for your configuration comes out when you put measured GB and event counts, and the unit prices from the official pricing page, into the formula above.
Change tiers before extending retention days
Before extending "from 30 days to 60 because 30 is not enough," fixing the order of decisions makes costs easier to read. First, see whether the volume put into the index can be reduced. The indexing rate acts in proportion to cost (lower it from 100% to 30% and the indexing cost becomes exactly 30%), while extending retention days acts only by the size of the unit price steps listed on the pricing page. Which is larger is decided by those steps and your own indexing rate. Next, match Standard retention to "the number of days you actually go back during investigations" from among 3 / 7 / 15 / 30 days, and for requirements beyond 30 days, change tiers to Flex or archives rather than extending Standard (price not published). Finally, decide the split between Flex and archives by search frequency. If you bring logs back weekly, the rehydration scan and re-indexing costs recur, so Flex suits; if a few times a year, archives suit. The default retention values, checking usage (how to check your costs), how to read the SKUs as a whole (How to Decode the Pricing Structure), and Live Tail for skimming logs right after arrival are each left to their own pages.