# Log tail > Something is happening now and the viewer needs to watch the raw events as they arrive. - Canonical: https://patterns.konigi.com/dashboards/log-tail - Group: Visual representation - Level: implementation - Status: published - Updated: September 10, 2026 - Also called: live tail, log stream --- ## Problem The deploy went out ninety seconds ago and something is wrong. Aggregates are five minutes behind and averaged into uselessness. The person watching needs the actual events, now, in order. ## Solution A stream of raw lines, newest arriving live, with enough structure layered on that a human can survive the volume. The ancestor is `tail -f` and the pattern has never really improved on its core promise: no aggregation, no delay, just what happened. Everything interesting is in what gets added on top without breaking that promise. Grafana's Explore is a good inventory of the necessary additions. **Live tail** streams new lines, and the detail that makes it usable is that new logs appear at the bottom with a contrasting background so the eye can track what is new against what was already there. Log level colouring recognises seven levels—critical, error, warning, info, debug, trace, unknown—from a `level` label, which turns a wall of monospace into something scannable. Deduplication offers **None**, **Exact** (matching whole lines, dates excluded), **Numbers** (ignoring numeric values) and **Signature**, the most aggressive. That last set matters more than it sounds: a retry loop emitting the same line four hundred times will otherwise flush every other event off the screen in seconds. The other necessary addition is a way out. A log line is evidence, and evidence is only useful attached to a request. Explore correlates logs with metrics, traces and profiles side by side, and carries compatible labels across when you switch data source. A tail without a route to the trace ID is a wall of text you have to leave in order to use. ## Use when Something is happening right now, the aggregate view has already told you roughly where, and you need the specifics. Deploys, incidents, and reproducing a bug against a known request. ## Don't use when The question is about frequency or trend. Watching a tail to judge how often something happens is a way to be badly wrong with high confidence; count it instead. And never as a monitoring surface, because a stream nobody is watching is not monitoring. ## Trade-offs Live tail is the only pattern here that punishes the viewer for looking away, and past a few hundred lines a minute it is unreadable by construction. Auto-scroll fights with the reader: pause and you fall behind, don't pause and you cannot read anything long enough to understand it. Retention is expensive, so the window you can tail is usually much shorter than the window you can aggregate. And the tail is deceptively persuasive—a vivid error scrolling past feels like the cause, and is often a downstream symptom that started later than whatever actually broke. ## Checklist - Is new content visually distinct from what was already on screen? - What happens above a few hundred lines a second, and does the UI say it is dropping? - Can the viewer pause without losing the buffer, and resume without losing their place? - Is there level colouring, and does it come from a real field rather than a regex on the text? - Is deduplication available, and does the viewer know it is on? - Can a line lead to the trace, the host, and the deploy? - Is the timestamp shown in a stated timezone, and does it match the charts nearby? - Can the viewer filter without leaving the stream and losing the tail? - How far back does the tail buffer go before it becomes a search instead? - Does a stalled stream look different from a quiet one? ## Compare **Grafana Explore** treats the tail as one signal among several and invests in the crossings: contrasting backgrounds for new lines, level colouring from a label, four deduplication modes, and label continuity when switching to metrics or traces. **Honeycomb** rejects the line-oriented framing, treating a log as a wide structured event so that what would be tailing becomes querying, which is better for questions and worse for the case where you genuinely do not yet know what to ask. **Sentry** never shows a raw stream at all; events are grouped into issues on arrival, which is the right default for errors and hides exactly the low-level noise a tail exists to surface. **Netdata** keeps a systemd journal view per node, so the tail is scoped to a machine you already suspect rather than to the estate. ## Related Trace waterfall is where a promising log line should lead. Filter bar is what makes a high-volume stream survivable. Search across panels is the same need at rest rather than live. Freshness indicator answers whether a quiet stream is quiet or broken. Error and stale state is what a stalled tail should be showing instead of nothing. ## Examples ### Grafana (Grafana Labs) The reference implementation for panel grids, template variables, and stat panels; most other tools are defined by how they differ from it. **Examples / Logs Panel** — captured September 10, 2026, Grafana Play (signed out; no version string exposed). operational, medium density, dark theme, desktop-web. The arrangement is the standard one and it is right: a stacked volume chart by log level across the top, then the raw stream underneath, so the shape of the traffic and the individual lines share one page. Two details are worth stopping on. Every line carries two timestamps in two timezones—the gutter reads 2026-09-10 18:36:58.435 in the browser's local time, and the JSON three characters later reads 2026-09-11T01:36:58.434956621Z in UTC. Same instant, seven hours apart, on the same row, and nothing labels either one. The second is the trace ID in the expanded panel at the bottom, which is the thing that makes a log line usable: it is the route from a line of text to the request it came from. Two of the three entries shown carry the identical trace ID, which is also the case deduplication exists for. Hotspots in this capture: - [Stacked composition](https://patterns.konigi.com/dashboards/stacked-composition) — Volume by level over time. The bottom band sits on a flat baseline; the two above it are approximate. - [Log tail](https://patterns.konigi.com/dashboards/log-tail) *(this pattern)* — Raw lines, truncated at the right edge, with two timestamps in two timezones on every row. - [Drill-down](https://patterns.konigi.com/dashboards/drill-down) — The trace ID: the route out of the wall of text and into the request that produced it. ## Related patterns - [Trace waterfall](https://patterns.konigi.com/dashboards/trace-waterfall) — One request touched twenty services and the viewer needs to see where the time went. - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — The viewer needs to narrow a large set by several attributes and see what's applied. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — The dashboard has sixty panels and the viewer knows the name of the one they want. - [Freshness indicator](https://patterns.konigi.com/dashboards/freshness-indicator) — The viewer is about to act on a number and doesn't know how old it is. - [Error and stale state](https://patterns.konigi.com/dashboards/error-and-stale-state) — One panel's query failed and the viewer must not mistake it for a zero. ## Sources - [Grafana, Logs in Explore](https://grafana.com/docs/grafana/latest/explore/logs-integration/) - [Bach et al., Dashboard Design Patterns](https://dashboarddesignpatterns.github.io/patterns.html) - [OpenTelemetry, Traces](https://opentelemetry.io/docs/concepts/signals/traces/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.