A platform has hundreds of dashboards and engineers cannot find the right one during an incident. How should dashboards be structured?

The problem with dashboard sprawl

Dashboards are created freely, for a specific investigation, and never deleted. Within a year there are hundreds, most reflecting a system that has changed, with no indication of which is authoritative. During an incident — the moment they matter most — finding the right one is a search problem under time pressure.

The structure that works

A three-level hierarchy, and only the first level is mandatory.

1. One service-health dashboard per service, from a shared template. Identical layout everywhere: SLI status, rate, errors, duration percentiles, saturation of the key resources, and the health of immediate dependencies. Because the layout is identical, an engineer can read a service they have never seen. This consistency is worth more than any individual dashboard's cleverness.

2. A small number of journey dashboards. Checkout, search, booking — showing the end-to-end user outcome and the contribution of each step. These are the ones an incident commander opens first, because they answer "what is the customer impact".

3. Investigation dashboards, created freely, clearly marked as ad hoc, and expiring automatically unless someone claims them. This is where sprawl is controlled: the mechanism is expiry, not discipline.

The properties that make them useful in an incident

• Consistent time range and consistent units across panels, so panels can be compared visually. Panels with different windows silently mislead.
• Deployment and configuration-change markers overlaid, because "what changed" is the first question in most incidents and the answer is usually visible on the timeline.
• Percentiles, never means, and segmented by whatever concentrates load.
• Exemplars linking a spike to a trace, so the dashboard is an entry point to investigation rather than a terminus.
• A link to the runbook from the dashboard, so the path from symptom to procedure is one click.

What dashboards should not be used for

Detection. Nobody is watching at 3 a.m. Detection is alerting's job; dashboards are for investigation after an alert fires and for understanding during normal work. Teams that rely on dashboards for detection have an on-call rotation staring at screens, which does not scale and does not work.

The maintenance rule

A dashboard nobody opened in ninety days should be deleted, automatically proposed. The value of a dashboard collection is inversely related to its size beyond a small number — because the cost of a large collection is paid in the seconds of confusion during every incident.