practice

Dashboards

Curated views built for a specific question — with the failure mode of showing everything and answering nothing.

dashboardsobservabilityincident-responsedesign

Definition

A dashboard is a saved set of visualisations. Its quality is determined entirely by whether it answers a question someone actually has, quickly, under stress.

The three kinds, which should not be mixed

1. The service health dashboard. One screen, no scrolling, answering "is this service healthy?" Rate, errors, duration, saturation, and dependency health. If someone must scroll, it is failing.

2. The incident dashboard. Built for a specific failure mode. "Database saturation" showing connections, slow queries, replication lag, and the endpoints affected. Linked from the runbook of the alert that fires for it.

3. The business dashboard. Orders per minute, signups, revenue. Frequently the fastest incident detector in the whole estate, because it measures what actually matters and is immune to every technical metric looking fine.

Mixing them produces a dashboard with forty panels that nobody reads under pressure.

Design rules

  • Most important at the top left. People read in that order, especially when panicking.
  • Include the comparison. A number without "same time last week" is uninterpretable — is 4,000 requests per second high?
  • Annotate deployments and configuration changes on the time axis. The single most valuable feature, because the answer to "what changed" is usually visible immediately.
  • Percentiles, not averages, on every latency panel.
  • Link to the next step — the trace query, the log query, the runbook.
  • Delete unused dashboards. A directory of 400 dashboards means nobody can find the right one, so everyone builds another.

Failure scenarios

  • The wall of graphs, impressive in a demo and useless in an incident.
  • Dashboards that require expertise to interpret, so only their author can use them — a single point of failure with a name.
  • Green dashboards during an outage, because everything measured is technical and nothing measures the user.
  • No time comparison, so normal and abnormal cannot be distinguished.
  • Dashboards as the alerting mechanism — someone is supposed to be watching, and nobody is.

Interview question

"Design the one dashboard your team would open first during an incident. What is on it and why?"