Datadog’s Live Tail feature lets you see logs as they’re generated, which sounds like tailing a file, but it’s actually a complex distributed system pushing events across networks and through multiple processing stages.

Let’s watch it in action. Imagine a web server generating access logs.

{
  "timestamp": "2023-10-27T10:00:01Z",
  "hostname": "webserver-01",
  "service": "nginx",
  "message": "192.168.1.10 - - [27/Oct/2023:10:00:01 +0000] \"GET /api/users HTTP/1.1\" 200 1234 \"-\" \"curl/7.68.0\"",
  "http": {
    "url": "/api/users",
    "status_code": 200
  }
}

When this log is written to disk, the Datadog Agent on webserver-01 picks it up. The Agent is configured to tail specific log files. It then forwards this raw log line to Datadog’s intake. Datadog’s backend ingests this, parses it (if configured), and makes it available for searching and for Live Tail. The Live Tail view pulls these processed logs from the ingestion stream, applying any filters you’ve set, and displays them in your browser in near real-time.

The core problem Live Tail solves is the latency between a log event occurring and being able to act on it. Traditional log aggregation systems involve batching, shipping, indexing, and then searching, which can take minutes. For debugging production issues, especially intermittent ones, that delay is unacceptable. Live Tail collapses this pipeline, showing you events within seconds of their generation.

Internally, the Datadog Agent uses a tailing mechanism that monitors file descriptors for changes. When new data is appended, it reads it. This data is then compressed and sent over a secure HTTP connection to a Datadog intake endpoint. At the Datadog side, this data enters a high-throughput ingestion pipeline. This pipeline includes parsing, enrichment (like adding metadata), and routing to various storage and processing systems. Live Tail specifically taps into this stream before it hits the main indexed storage, allowing for low-latency access. Filters you apply in the Live Tail UI are processed at the edge of the Datadog backend or even client-side to reduce the volume of data you see, without altering the underlying ingestion.

You control Live Tail primarily through its filtering capabilities. You can filter by host, service, status code, or any custom tag or attribute present in your logs. For example, to see only ERROR level logs from your backend service on webserver-01, you’d use a query like:

service:backend host:webserver-01 status:error

This query is evaluated against the incoming log stream. The system is designed to handle massive volumes of logs; the challenge is ensuring your filters are specific enough to be useful without being so narrow that you miss critical context.

The one thing most people don’t realize is that Live Tail isn’t just showing you raw text. Behind the scenes, Datadog is actively parsing and structuring your logs during ingestion. Even if you’re just tailing a plain text file, Datadog’s system attempts to infer structure or uses pre-defined parsers based on your Agent configuration. This means that even in Live Tail, you can often filter not just by the raw message content, but by extracted attributes like http.status_code, user_id, or request.method, making the "live tail" experience far more powerful than a simple tail -f.

The next step is understanding how to leverage Live Tail for automated alerting on critical real-time events.

Want structured learning?

Take the full Datadog course →