Dashboards

A dashboard exists to answer a specific question fast, under pressure, for a specific person. Most dashboards fail that job not because the data is wrong but because they were built to show everything available rather than to answer anything in particular — thirty panels of "might be useful," none of which the on-call engineer can parse in the first ninety seconds of an incident.

That's a design failure, not a data failure — every one of those thirty panels might be technically correct and still add up to a dashboard nobody can act on under pressure.

Treat dashboard-building as an editing exercise, not an exporting one — the value is almost always in what you deliberately leave out.

If you can't say which question a dashboard answers and for whom, it will be built once and never opened again.

A dashboard is a designed answer to a question, not an export of every metric a service happens to emit.

1. Name the question and the audience before building a single panel

"Show me service health" is not a question, it's a mission statement. "Is this service currently causing the checkout failures customers are reporting" is a question, and it implies a very different, narrower set of panels than "show me everything about the payment service."

The narrower question is almost always the more useful dashboard, because it maps directly onto a decision someone actually needs to make. Every dashboard should be buildable to a one-sentence brief: