Dashboard Hierarchy
Organising dashboards into service-level, diagnostic and deep-dive layers so each answers a specific question at a specific moment.
The common failure is a wall of forty graphs that answers nothing under pressure. Dashboards are read by a stressed person at 03:00, and that is the design constraint.
Layer one — service health. Four to six panels: SLI against SLO, error budget remaining, the four golden signals, current alerts. Answers "is something wrong and how bad?" in five seconds.
Layer two — diagnosis. Broken down by endpoint, dependency, region and version. Answers "where is it wrong?" Deployment markers on the time axis belong here, because a large share of incidents correlate with a change and this is the fastest way to see it.
Layer three — deep dive. Per-component detail, used rarely and deliberately.
Practices that separate useful dashboards from decorative ones: thresholds drawn on the graph so a value is interpretable without knowing what normal is; comparison to the previous week so seasonality is not mistaken for an incident; consistent time ranges across panels; and a linked runbook.
And they must be maintained — a dashboard showing metrics that no longer exist actively misleads during an incident, which is worse than having no dashboard at all.