What is the expected latency between log ingestion and search availability in Log Explorer?

The short answer

For standard Datadog log ingestion, logs typically become searchable in the Log Explorer within a few seconds of ingestion — commonly under roughly 10 seconds under normal load. There is no hard, guaranteed maximum latency window published as an SLA: indexing delay is a best-effort behavior that scales with ingest volume, indexing load, and regional service health. During bursts or heavy shared load, the gap can stretch to tens of seconds or, in some cases, around a minute.

Why the gap exists

The behavior you describe — visible in the raw stream, absent from search — is a consequence of the two-stage pipeline:

1. Streaming/ingestion stage. Logs are accepted and made available to the stream almost immediately. Live Tail reads from this stage, which is why it appears "real time" — it bypasses indexing entirely.
2. Indexing stage. Logs are processed (parsed, attributed, filtered by your index configuration) and committed to the searchable index. Only after this commit do filtered Log Explorer queries return them.

So Live Tail visibility and Log Explorer visibility are not two views of the same state — they read from different points in the pipeline. A log can legitimately exist in one and not the other for a short window.

Factors that influence the delay

• Ingest volume and burstiness. Sudden spikes queue work ahead of your logs in the indexing stage.
• Index configuration. Which indexes a log matches, and how much processing (pipelines, parsing, remappers) runs before indexing, adds time.
• Exclusion filters and sampling. These change what gets indexed but not the fundamental commit cadence.
• Plan and shared-resource load. Accounts on shared infrastructure can see longer tails during platform-wide peak periods.
• Regional service health. Degradation in the logs backend shows up first as indexing lag.

Is there a defined maximum?

No contractual maximum is documented for this transition — treat "a few seconds, occasionally tens of seconds" as the expected range, not a guarantee. If you consistently observe delays beyond a minute under normal load, that is outside the typical envelope and worth investigating as a possible throttling, pipeline misconfiguration, or backend issue rather than accepting as normal.

How to measure it yourself

1. Emit a test log with a unique marker and a known UTC timestamp, e.g. {"marker":"lat-check-20261015","ts":"2026-10-15T02:20:00Z"}.
2. Immediately query Log Explorer filtered on that marker, polling every few seconds, and record when the log first appears.
3. Compute observed latency as search-available time minus ingest timestamp.
4. Repeat during normal load and during your peak ingest window to see how the delay scales.

If your organization monitors Datadog usage metrics, check for platform-reported indexing lag under Usage / Logs to corroborate your measurements.

Practical implication for alerting

Because search depends on the completed index, monitors that query very recent log windows can miss events still in the indexing buffer. A common mitigation is to evaluate monitors against a window that ends a minute or more in the past, accepting slightly delayed alerts in exchange for not silently skipping unindexed logs.

Caveats

The figures above reflect generally documented and observed behavior as of this writing; Datadog does not publish a firm latency SLA for indexing, and actual values vary by account, region, and load. If a precise bound matters for your use case (e.g., compliance or incident response timing), confirm current expectations with Datadog support for your plan rather than relying on community-observed numbers.