A single Datadog log can move through several distinct cost stages, and each stage is governed by a different control.
Short answer
Datadog log cost is not one number. It is the sum of separate, independently governed stages: what your systems generate, what actually reaches Datadog as ingestion, what is selected for indexing, how long each index retains searchable data, and what happens to everything else. Datadog calls this model Logging without Limits™: ingest broadly, then decide deliberately what becomes searchable. Ingested logs are billed by the volume submitted to the Logs service; indexed logs are billed separately, per event, at a rate tied to the retention period selected for the index that receives them. Reducing the bill safely means understanding which stage a given change actually affects, because a change at one stage does not automatically change the others.
Why "log cost" is the wrong mental model
Teams under budget pressure often ask a single question: how do we make our logs cheaper. The question assumes log cost is one meter. Datadog's architecture treats it as several.
A log event can be:
- generated by an application or piece of infrastructure;
- collected by an Agent, a forwarder, or a direct API call;
- ingested into Datadog's Logs service;
- routed to zero, one, or more indexes;
- indexed and made searchable, or excluded from indexing;
- retained for a configured period, then removed from the index;
- optionally archived to external cloud storage;
- optionally rehydrated back into a searchable state later.
Each of these stages is controlled independently, and each can be changed without changing the others. Turning off an exclusion filter changes what gets indexed, not what gets ingested. Shortening retention changes how long indexed data stays searchable, not whether it was ingested. Configuring an archive changes what survives after removal from an index, not what was indexed in the first place.
This article covers the mechanics of that pipeline specifically for Datadog. For the broader, vendor-neutral version of this cost chain across logs, metrics and traces, see Observability Cost Optimization: Where Your Logs, Metrics and Traces Budget Actually Goes. For the wider list of Datadog configuration mistakes that inflate spend across every product, see Datadog Bill Too High? 12 Configuration Mistakes That Inflate Observability Costs.
Ingestion: the volume that reaches Datadog
Datadog bills log ingestion based on the total volume of data submitted to the Logs service, independent of whether that data is later indexed. Ingestion is the entry cost: it applies the moment a log event reaches Datadog, before any indexing decision is made.
This has a direct architectural consequence. A log excluded from every index still counts as ingested if it reached the Datadog Logs intake. The only way to avoid the ingestion cost for a given event is to prevent it from reaching Datadog in the first place — filtering at the Agent, at a log shipper, or in a processing layer positioned before the Datadog intake, rather than filtering only inside Datadog itself.
Ingestion is also where Datadog applies parsing, enrichment, tagging and routing, which is why the ingested stream is the raw material for every downstream decision: which index a log enters, which exclusion filter evaluates it, and what metrics or archives are generated from it.
Indexing: what becomes searchable, and at what price
Indexing is the second, separately billed stage. Datadog charges for indexed logs per million log events submitted for indexing, at a rate that corresponds to the retention policy assigned to the index receiving them. Longer retention on an index costs more per indexed event than shorter retention on the same index, because Datadog is charging for retained, searchable capacity, not merely for the act of writing the event once.
Two logs of identical size can therefore have very different economics. A 2 KB log line placed into a 3-day retention index that is rarely searched is a small cost. The same 2 KB log line placed into a 90-day retention index used for compliance search is a materially larger cost, even though the ingestion charge for both was identical.
Index filters decide which index a log enters
Each Datadog log index has an index filter. Logs are evaluated against indexes in order, and a log enters the first index whose filter it matches — index order therefore functions as routing priority, not merely as a list of destinations. A common pattern is to route status:error logs into a retention-heavy index and route routine status:info logs into a short-retention or excluded index.
Exclusion filters decide what inside that index gets skipped
Within an index, exclusion filters remove logs from indexing based on a query and an optional sampling rate. Datadog processes each log against only the first active exclusion filter it matches, so filter order changes behavior, not just documentation clarity. Exclusion filters can operate at 0–100% sampling, either per individual log or grouped by a specific attribute such as a trace ID or user identifier — which allows a team to keep, for example, 5% of a noisy log pattern for statistical visibility while discarding the rest from the index.
A log excluded from indexing is not deleted. It is discarded from the index specifically. It still flows through Live Tail, can still be used to generate metrics from logs, and can still be sent to an archive — which is why exclusion filters change search cost without necessarily eliminating the underlying signal.
Daily quotas are a hard backstop, not a filter
Each index can also carry a daily quota, measured in millions of events, that hard-limits how much is indexed per day regardless of what the index and exclusion filters would otherwise allow. Once the quota is reached, additional matching logs stop being indexed for the remainder of the period, but — like excluded logs — they continue to flow through Live Tail, archives and log-based metrics. A quota is a ceiling on indexed volume; it does not change ingestion, and teams relying on it as their primary cost control should treat quota breaches as an operational signal that upstream filtering or routing needs revisiting, not as a silent, permanent cap.
Retention: a property of the index, and a property of the data
Retention determines how long an indexed log remains searchable before it ages out of the index. Because indexed pricing is tied to the retention period configured on the index, retention is not a settings toggle with no cost consequence — it is one of the two primary levers (alongside indexed volume) that determines what an index actually costs.
The practical design implication is that a single retention period applied uniformly across an entire log estate is rarely the right architecture. A production error stream actively used during incident response has different retention requirements than a routine access log kept mainly for historical reference, which again differs from an audit log retained primarily for a compliance obligation rather than day-to-day search. Datadog's own best-practice guidance for log management centers on exactly this kind of segmentation: multiple indexes, each with a retention period and daily quota matched to the value of the data it holds, rather than one index for everything.
Beyond standard indexing: Flex Logs and long-term searchable storage
Standard indexing is built for data that needs to be searched quickly, close to the time it was generated. It is not the only tier Datadog offers for data that needs to remain searchable for much longer without the same query latency requirements.
Datadog's Flex Logs tier decouples storage cost from compute cost, aimed specifically at high-volume logs that organizations need to retain for months or years and only need to query occasionally rather than continuously. Within that tier, Flex Frozen extends retention up to seven years while keeping the data searchable through Archive Search, at a storage price point Datadog has publicly described as $0.05 per million events per month — without requiring rehydration or an externally managed archive to regain searchability.
This matters for the indexing-versus-retention decision above: data that must remain available for a regulatory or audit reason, but that is not part of routine operational search, is frequently a poor fit for standard long-retention indexing and a much better fit for a Flex tier. Standard indexing prices continuous searchability at short latency; Flex trades some of that latency for materially lower long-term storage economics.
Archives and rehydration: what happens after data leaves the index
For logs that should be retained outside the indexing/retention model entirely — for compliance, for historical record, or simply because the organization does not want to pay for years of indexed retention on data it rarely needs — Datadog supports archiving to external cloud storage: Amazon S3, Azure Storage or Google Cloud Storage, each configured with its own authentication model (IAM role delegation for S3, an Azure AD role assignment for Azure, a service account role for GCS).
Archived logs are not searchable in Datadog by default. Two mechanisms restore access to them, and they have different cost profiles:
Rehydration is a background batch job that re-indexes archived logs for a specified time window back into a searchable state in Datadog. It operates through time-scoped "historical views," and — critically for cost planning — the query filter is applied after the archived files are downloaded and scanned, so the billable scan size reflects the full volume retrieved for the window, not the volume matching the query. Datadog's own documentation is explicit that scanned and indexed logs from a rehydration are billed even if the rehydration job is canceled partway through.
Archive Search is a real-time search directly against the object storage archive, without a re-indexing step, billed for the data scanned rather than for a rehydrate-then-index cycle. Datadog positions this as generally the more cost-efficient path for occasional lookups into archived data, reserving rehydration for cases where the retrieved window needs to persist in Datadog as a normal searchable dataset for a period of active investigation.
The architectural decision is therefore not simply "archive or don't archive." It is: which of three future access patterns does this data actually need — continuous fast search (standard indexing), occasional search at lower cost (Flex), or rare, plannable retrieval (archive plus Archive Search or rehydration)?
The Datadog log pipeline in one table
| Stage | What it controls | Billed as | Common mistake |
|---|---|---|---|
| Generation | What applications and infrastructure emit | Not billed directly | Verbose or duplicate logging by default |
| Collection | What the Agent or shipper forwards | Not billed directly | No filtering before the Datadog intake |
| Ingestion | Volume submitted to the Logs service | Per GB ingested | Assuming exclusion filters reduce this |
| Index routing | Which index a log enters | N/A (routing logic) | Overlapping or misordered index filters |
| Exclusion filtering | What is skipped from an index | N/A (reduces indexed volume) | No exclusion filters on high-volume debug logs |
| Indexing | What is searchable, and for how long | Per million indexed events, by retention tier | One retention period for all data classes |
| Daily quota | Hard ceiling on indexed volume per day | Caps indexed billing, not ingestion | Treated as a cost control instead of a safety net |
| Flex / Flex Frozen | Long-term searchable storage at lower compute cost | Per million events, storage-priced | Keeping long-tail compliance data on standard indexing |
| Archive | Long-term retention outside the index | External storage cost | No archive at all, or archiving without a retrieval plan |
| Rehydration / Archive Search | Restoring searchability from an archive | Scan volume (Archive Search) or full window (rehydration) | Rehydrating a broad window instead of using Archive Search |
A decision framework for what belongs where
Before changing any single setting, classify the log stream, not the log line. A useful set of questions for each material log source:
- Is this stream actively used during incident response? If yes, it likely needs standard indexing at a retention long enough to cover a realistic investigation window.
- Is this stream reviewed rarely, but must exist for audit or compliance reasons? It is a Flex or archive candidate, not a long-retention standard index candidate.
- Does this stream contain mostly repetitive, low-information events (health checks, routine debug output, expected retries)? It is an exclusion-filter or pre-ingestion-filter candidate.
- Is the stream currently ingested and indexed identically to every other stream, without anyone having reviewed whether that is still appropriate? That absence of review is itself the finding — see the governance checklist in Datadog Bill Too High? 12 Configuration Mistakes That Inflate Observability Costs for the broader pattern.
This decision should be made per data class, owned by the team that understands what the data is for, not applied uniformly by a platform team optimizing a single dashboard number. Where the decision has financial implications significant enough to need sign-off from finance or procurement — a pending Datadog renewal, for example — connect this analysis to How to Audit Datadog Costs Before Your Next Renewal, which covers how to turn a log-cost review into renewal evidence.
What this article does not cover
Custom metrics generated from logs, and the cardinality those metrics can carry, are governed by a separate set of Datadog mechanics covered in Datadog Custom Metrics and Cardinality: How Costs Grow. Cost attribution — connecting a given log stream's cost back to the team or service that owns it — is covered in Observability FinOps: How to Allocate Costs by Team, Service and Environment. This article is deliberately scoped to the mechanics of the log pipeline itself.
When this becomes an architecture decision, not a settings change
A log-cost review is a configuration exercise when the finding is "this index has no exclusion filter" or "this retention period was never revisited." It becomes an architecture decision when the finding is structural: log volume is growing faster than the business the logs describe, multiple teams have built incompatible indexing conventions, or the organization cannot currently answer which log streams are load-bearing for incident response and which are historical noise.
A vendor-neutral Observability Cost Audit examines the full log pipeline — generation, ingestion, index design, exclusion filters, retention tiers, archive strategy — against what engineering and compliance teams actually need, and separates changes that are safe to make immediately from those that require broader review.
FAQ
Ingested logs are the total volume submitted to Datadog's Logs service and are billed by volume regardless of whether they are later searchable. Indexed logs are the subset selected, through index filters and exclusion filters, to become searchable, and are billed separately per million events at a rate tied to the retention period of the index they enter.
Excluding a log from an index removes it from indexed billing, but not from ingestion billing if it already reached Datadog's Logs intake. The log still flows through Live Tail, can still generate log-based metrics, and can still be archived. To avoid the ingestion charge entirely, filtering has to happen before the log reaches Datadog, not only inside a Datadog exclusion filter.
Indexed log pricing in Datadog is tied to the retention period configured on the index that receives the log. Longer retention on an index costs more per indexed event than shorter retention, because the price reflects sustained searchable capacity rather than a one-time write. Segmenting logs into indexes with retention matched to actual need, rather than one retention period for everything, is the primary lever here.
A daily quota is a hard limit, measured in millions of events, on how many logs a given index will accept per day. Once reached, additional matching logs stop being indexed for the rest of the period but continue to flow through Live Tail, archives and log-based metrics. It functions as a safety ceiling rather than a substitute for exclusion filters or index design.
Flex Logs are a Datadog storage tier that separates compute cost from long-term storage cost, intended for high-volume logs that need to remain searchable for months or years but are queried only occasionally. Flex Frozen extends this to retention as long as seven years while keeping the data searchable via Archive Search. It is generally a better fit than standard long-retention indexing for compliance or audit logs that are rarely part of day-to-day operational search.
Rehydration re-indexes a time-scoped window of archived logs back into a searchable state in Datadog and bills for the full volume scanned in that window, even if the job is canceled before completion. Archive Search queries the archive directly, in real time, without a re-indexing step, and bills only for the data scanned by the query. Archive Search is generally the lower-cost option for occasional lookups; rehydration makes more sense when a dataset needs to persist as an actively searchable index for a period of investigation.
Start by classifying log streams by actual use — active incident-response data, rarely queried compliance data, and low-information repetitive events each belong on a different tier (standard indexing, Flex or archive, and exclusion filtering, respectively). Filter unnecessary volume as close to the source as possible, since filtering inside Datadog after ingestion does not reduce the ingestion charge. Review index retention per data class rather than applying one period everywhere.
Sources
- Datadog — Log Configuration: Indexes (index filters, exclusion filters, retention, daily quotas).
- Datadog — Rehydrating from Archives (rehydration mechanics and billing notes).
- Datadog — Flex Logs (Datadog blog): storage/compute separation, Flex Frozen, Archive Search.
- Datadog — Best Practices for Log Management (index segmentation guidance).
- Datadog — Logging without Limits™ Guide (ingestion vs. indexing model).
Datadog pricing, packaging, product names and billing mechanics change. Validate current figures against Datadog's own pricing and billing documentation and the commercial agreement applicable to your organization.