# Status history > The viewer needs to see when something was up, down, or degraded, over days, in one row. - Canonical: https://patterns.konigi.com/dashboards/status-history - Group: Visual representation - Level: implementation - Status: published - Updated: September 10, 2026 - Also called: state timeline, uptime bar, availability strip --- ## Problem Was it down last Tuesday? For how long? A line chart of a binary metric is a square wave nobody can read at a month's width, and an incident log is a list of things somebody remembered to write down. ## Solution One row per thing, time along the x-axis, colour for state. Continuous coloured regions, so a week of health is a long green bar and an outage is a red notch you can see from across the room. The encoding change matters. A time series asks the viewer to read a value and mentally threshold it. A status history has already done the thresholding and shows the conclusion, which is what makes a month of history readable in a strip a few pixels tall. Grafana splits this into two panels and the split is instructive. The state timeline draws state as continuous regions and carries **Merge equal consecutive values**, which controls whether identical adjacent values are joined into one block. With merging on, a month of "up" is a single bar and the notches are unmissable. With it off, you see every sample, which matters when the sampling interval is itself the story. **Show values** offers Auto, Always and Never for labelling regions in place. Value mappings turn raw values into named states with colours, and thresholds can convert an ordinary numeric series into discrete coloured regions, which is how a CPU metric becomes a health strip without a separate query. The status history panel is the discrete-sample sibling: one mark per sample rather than a continuous region, which suits checks that run on a fixed schedule where the gaps between them are real rather than interpolated. ## Use when The state is categorical and low-cardinality, and the question spans a period longer than a chart can show usefully. Uptime, deployment state, check results, on-call coverage, batch job outcomes. ## Don't use when The underlying value is continuous and the magnitude matters. Reducing latency to green/amber/red loses the difference between 210ms and 900ms, and both are amber. ## Trade-offs The whole pattern rests on a thresholding decision made somewhere else, usually invisibly, and a status strip inherits every flaw in it while looking authoritative. Brief outages disappear below one pixel at wide time ranges, so a strip showing a clean month may be hiding forty two-minute blips. Merging consecutive values makes the display readable and destroys the distinction between "we checked continuously" and "we checked twice". And a row per entity does not scale: forty rows is a wall of colour with no ordering principle unless somebody supplies one. ## Checklist - What turns the underlying data into a state, and where does that rule live? - How many distinct states, and is that few enough to read as colour alone? - What does a gap mean: healthy, unknown, or not-yet-checked? - Are consecutive equal values merged, and does that hide the sampling interval? - At the widest range shown, how short an outage becomes invisible? - Is there a hover giving exact start, end and duration? - Is the row order meaningful, and is it stable between visits? - Would a colourblind viewer distinguish degraded from down? - Can the viewer get from a red region to what caused it? - Does the strip agree with the incident record, and if not, which is wrong? ## Compare **Grafana** ships two panels for this and the choice between them is the design decision: state timeline for continuous regions with merging, status history for one mark per discrete sample. **Public status pages** in the Statuspage mould reduce it to the minimum honest form—one bar per component per day, ninety days across—which is the most-read version of this pattern anywhere and the one most tuned for readers with no context. **Datadog** ties the strip to monitor state rather than to raw metrics, so the history you read is the history of what actually paged someone. **Netdata** keeps alarm transitions per node in a log-shaped view, which trades the instant scan for exact times and reasons. ## Related Threshold line is where the rule that produces these states usually gets drawn. Semantic status color governs the palette and is what makes the strip readable or not. Error and stale state covers the case this pattern most often gets wrong, which is a gap that means "unknown". Time series is the continuous version this replaces. Annotation is how the cause gets attached to the notch. ## 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 / State timeline and Status history** — captured September 10, 2026, Grafana Play (signed out; no version string exposed). operational, medium density, dark theme, desktop-web. The most useful thing on this page is an accident of layout: the third panel down the left column draws three series as state bands, and the panel directly underneath draws the identical query as an ordinary time series. Same data, stacked one above the other. The line chart is three tangled traces oscillating between 57 and 64, and reading it means picking a series, tracing it, and thresholding it in your head. The state timeline above has already done that and shows the conclusion, and the blue stretches—below fifty—are findable without being looked for. That is the whole argument for the encoding, and Grafana has put the before and after in adjacent panels. Worth noticing too that every coloured region here carries its word inside it. LOW, HIGH, NORMAL, CRITICAL, True, False. Colour is never the only carrier on this page. Hotspots in this capture: - [Status history](https://patterns.konigi.com/dashboards/status-history) *(this pattern)* — Continuous regions with the state name written inside each one. - [Threshold line and region](https://patterns.konigi.com/dashboards/threshold-line) — Thresholds turning a numeric series into discrete bands: under 50, 50, 300. - [Time series](https://patterns.konigi.com/dashboards/time-series) — The same query as the panel above, untranslated. Three traces you have to threshold yourself. - [Sequential and diverging scales](https://patterns.konigi.com/dashboards/sequential-and-diverging-scales) — One mark per sample, green through red by temperature—so green here means cold, not good. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — A closed set of two, both labelled. The clearest case on the page of colour plus a word. ## Related patterns - [Threshold line and region](https://patterns.konigi.com/dashboards/threshold-line) — A flat metric has a line it must not cross, and the chart should show where that line is. - [Semantic status color](https://patterns.konigi.com/dashboards/semantic-status-color) — State has to be readable before the number 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. - [Time series](https://patterns.konigi.com/dashboards/time-series) — The viewer needs to see how a value changed over time and spot the moment it changed. - [Annotation](https://patterns.konigi.com/dashboards/annotation) — A change in the line has a cause, and the viewer shouldn't have to go find it elsewhere. ## Sources - [Grafana, State timeline panel](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/visualizations/state-timeline/) - [Grafana, Status history panel](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/visualizations/status-history/) - [Bach et al., Dashboard Design Patterns](https://dashboarddesignpatterns.github.io/patterns.html) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.