Most organizations have far more dashboards than they use. They accumulate the same way alerts do: someone builds one during an incident, it is useful for a week, and then it sits there. Two years later there are ninety, four of them are opened regularly, and nobody can tell which four without checking.
The cost is not storage. It is that during an incident, the responder has to choose, and choosing badly wastes the most expensive minutes of the whole event.
Build for a question, not for a system
The dashboards that survive are the ones that answer a specific question somebody actually asks. "Is the checkout path healthy right now" is a question. "Payments service" is a topic, and a dashboard built around a topic ends up as an undifferentiated wall of every metric the service emits.
When I am reviewing one, the test I use is whether someone unfamiliar with the service could look at it for ten seconds and say whether things are fine. If they have to know which of the twenty panels matters, the dashboard is a data source rather than an instrument.
A shape that works
The layout that has held up best for me is three tiers, top to bottom.
At the top, the handful of numbers that describe the user experience: success rate, latency at a couple of percentiles, throughput. Big, few, and unambiguous. This tier answers "is there a problem."
Below that, the immediate suspects: dependency health, error breakdown by type, queue depths, saturation on whatever the known bottleneck is. This tier answers "where is it."
At the bottom, the detail you only want once you have a hypothesis. Per-instance metrics, cache statistics, the long tail. This tier is for confirming, not for browsing.
Percentiles, not averages
An average latency graph is close to useless for anything user-facing. It hides exactly the population you care about. A service can have a perfectly healthy average while a tenth of requests are timing out, and that tenth is where the complaints come from.
Show the middle and the tail together. The gap between them is often more informative than either number alone, because a widening gap usually means something has started queueing.
Delete aggressively
The maintenance habit that matters most is deletion. Once or twice a year, look at view counts if your tooling has them, and archive anything nobody has opened. This feels destructive and is not. A dashboard nobody opens is not providing value, it is providing choice, and during an incident choice is a cost.
The remaining set should be small enough that a new person can be shown all of it in one sitting. That is a reasonable target, and most teams are a long way from it.