I was asked a simple question recently: what makes a good dashboard?
My short answer was that a good dashboard should be instinctively readable. A person who understands the system should be able to tell, quickly, whether it is healthy or not. If they cannot, the dashboard may still be full of useful metrics, but it is not yet doing its job.
The longer answer is more interesting, because dashboards sit right on the line between engineering, operations and product thinking. They are not decoration for observability data. They are part of the interface between a team and the system it runs.
Start with the decision
The first question is not, “Which metrics can we graph?”
It is, “What decision should this dashboard help someone make?”
For a service dashboard, that might be:
- are users affected?
- is the service inside its SLO?
- did this begin after a deploy, feature flag or configuration change?
- is demand higher than usual, or is the system processing work more slowly?
- where should I go next if the top-level view looks wrong?
That framing changes the shape of the dashboard. It pushes the most important signals to the top, removes panels that only exist because the data was easy to fetch, and makes room for context.
A dashboard that supports no decision becomes a reporting surface. Reporting has its place, but it is a poor substitute for operational clarity.
Show the happy path
Good dashboards make the normal path obvious.
For many systems, that means starting with the golden signals: request rate, error rate, latency and saturation. For a queue-driven platform, it also means showing work creation rate, completion rate, queue depth and the age of the oldest item. For a controller-based system, reconciliation rate and error rate matter more than another CPU graph.
The point is not to follow a fixed template. It is to show the path work takes through the system, then make deviations visible.
If the dashboard cannot show a healthy baseline, it will struggle to show an unhealthy one. Engineers end up reading each panel in isolation, asking whether a number feels high, then hunting through other tools for the missing shape of the system.
Make change visible
Many incidents begin with a change.
That change might be a deploy, a feature flag, a routing update, a new tenant, a certificate rotation, a scaling policy change or a dependency behaving differently. When the dashboard does not show that context, responders have to rebuild the timeline manually while the system is already degraded.
I like dashboards that annotate change directly on the graphs where the change would matter. A latency spike with a deploy marker is easier to reason about than a latency spike and a separate Slack thread. A queue depth increase beside a producer rollout gives the responder a first hypothesis without pretending to be a root cause.
The dashboard should not try to answer everything. It should make the next question cheaper.
A queue can hide the incident
One production incident has stayed with me because the first visible symptom was not the real shape of the failure.
A software change started publishing messages continuously to a Pub/Sub topic. By the time the problem was found, there were around 13,000 messages queued and Kubernetes had spent the weekend trying to scale after the work being created. The platform automation was doing what it had been asked to do. That was the problem.
At first, the obvious view was scheduling pressure: unschedulable pods, more nodes, a slow control plane. The more useful view was the feedback loop: messages arriving faster than they could be processed, automation creating more work, and the operational components needed for recovery competing with the workloads they were creating.
Argo Events being unschedulable was a particularly sharp lesson. The component that helped process platform events had a lower priority than the workloads being created from those events. When it came back, it helped trigger another wave of namespace creation.
A better dashboard would not have prevented every bad decision. It would have made the runaway pattern visible earlier.
Avoid
A wall of symptoms
- CPU, memory and pod counts dominate the first screen.
- Queue depth appears without ingress, egress or oldest-item age.
- Deploys and configuration changes live in another tool.
- Every panel asks the responder to decide what matters.
Prefer
A path to a decision
- User impact, SLO burn and saturation are visible first.
- Work creation, completion and queue age are shown together.
- Deploys, flags and config changes annotate the timeline.
- Links lead to owners, runbooks and deeper diagnostic views.
Keep the first screen honest
A useful dashboard has hierarchy.
The first screen should answer: are we okay, and where is the likely pressure? Deeper dashboards can hold the details: per-tenant breakdowns, controller internals, node-level views, database metrics, cloud-provider limits and application traces.
Trying to put every possible question on one page makes the dashboard harder to trust under pressure. It also encourages a familiar failure mode: teams add panels after every incident until the page describes the organisation’s anxiety better than it describes the system.
Post-incident dashboard work should be disciplined. Add the signal that would have changed the response. Remove the panel nobody used. Prefer upstream indicators that predict failure over downstream indicators that confirm it after users already know.
A predictive disk-fill alert is a good example. “This disk will fill in the next 24 hours” is more useful than 200 static threshold alerts that teach people to ignore storage noise until it becomes urgent.
Put instructions near the signal
I like a short description at the top of an operational dashboard. Not a wiki page. Just enough to tell a responder what the dashboard is for, what healthy usually looks like and where to go next.
Good context includes:
- the user journey or system path represented by the dashboard;
- the SLI or SLO the page is anchored to;
- the owner or escalation route;
- links to deeper dashboards and runbooks;
- any known blind spots in the signals.
That last point matters. A dashboard that is honest about what it cannot see is more useful than one that implies completeness.
Alerts and dashboards should agree
Alerts should bring a human to the right question. Dashboards should help that human answer it.
When the alert and dashboard are designed separately, on-call becomes harder than it needs to be. The alert says one thing, the dashboard opens somewhere else, and the responder has to translate between detection and diagnosis.
The alert should land on the dashboard view that explains why the alert fired, how severe the impact is and which neighbouring signals confirm or challenge the hypothesis. If an alert self-resolves often, or would not justify waking someone at 2am, it probably needs a better upstream signal or a different route.
Where I land
A good dashboard reduces decision time without removing engineering judgement. It shows the happy path, makes change visible, groups related signals together and gives responders a clear next step.
The best ones feel almost boring when the system is healthy. Under pressure, that boring clarity is the point.