The dashboard nobody looks at

Open your monitoring tool and count the dashboards. Now check when each was last viewed — most tools will tell you.

The distribution is always the same: three dashboards carry all the traffic and forty have not been opened in a year.

why they accumulate#

Dashboards get created during incidents. Someone needs to see a specific correlation right now, builds a view, the incident ends, and the dashboard stays — specific to a problem that has been fixed, named something like "orders debug 2," owned by nobody.

Nothing removes them, so they accumulate until finding the useful one requires knowing its name in advance.

the three that earn their place#

The service dashboard. One per service, same layout for every service, so that anyone can read any service's dashboard without orientation. Rate, errors, duration, saturation. Six to eight panels, above the fold, no scrolling.

The consistency is the point. When every service looks the same, an engineer responding to an unfamiliar service already knows where to look.

The journey dashboard. One per critical user journey — checkout, signup, search. Not per service: per outcome, end to end, across every service involved.

This is the one most organisations lack, and it is the one that answers the question that matters during an incident: are users able to do the thing? Every service being green while checkout is broken is a common and confusing state, and only a journey view shows it.

The capacity dashboard. Resource headroom over weeks, not minutes. Reviewed on a schedule, not during incidents. This is the only one meant for planning rather than response.

what makes a panel useful#

A threshold drawn on it. A line with no reference is a shape. A line with "target: 200ms" drawn across it is information. Every latency and error panel should show what "fine" is.

Comparison to last week. Most values are meaningless in isolation. 4,000 requests per minute — is that high? The same panel with last week's line overlaid answers instantly.

A unit and a direction. Label it. State whether up is good. This sounds trivial and half of all panels fail it.

Percentiles, not averages, for anything latency-shaped. And show p50 next to p99: the gap between them is often the real signal.

Fewer panels. A dashboard with forty panels is a data dump. During an incident nobody scrolls. Eight panels that fit on a screen beat forty that do not.

the annotations that make it work#

The highest-value dashboard feature is the least used: deploy markers.

Vertical lines on every time series showing when a deploy happened. Most tools support it and most teams have not wired it up.

With them, "did this start after the deploy?" is answered by looking. Without them it is answered by opening another tab, finding the deploy log, and correlating timestamps by hand — during an incident, under pressure.

Add config changes and feature flag flips to the same annotation stream and you have covered the causes of most self-inflicted incidents.

the maintenance rule#

Delete dashboards nobody opens. Quarterly, using the view counts your tool already records. If someone misses one, they can rebuild it, and the rebuild will be better because it will reflect the current system.

Give every dashboard an owner and a purpose in its description. "Used by on-call to triage checkout failures" tells the next person whether to trust it. An unlabelled dashboard is one nobody dares delete and nobody quite believes.

the test#

During your next incident, notice which dashboard you actually opened first.

That is your real service dashboard. Whether it is the one you designated as such, and how much of what you needed was on it, is the most honest review of your monitoring you will ever get — and it costs nothing but paying attention for five minutes while you are already there.