Nobody Looks at Your Dashboard Until Something Is Already Broken

We had forty dashboards. During the postmortem for a recent incident, I asked when anyone had last looked at the relevant one before the incident started. The honest answer was never. It had been built during a project, shown in a demo, admired, and then visited only by the person investigating the failure it failed to prevent.

Here is the thesis. Most dashboards are not monitoring. They are a museum of metrics, built to reassure the people who built them, and read only after the outcome they were meant to change has already happened. The failure is not in the tooling. It is in the absence of a behaviour that the dashboard is supposed to trigger.

The test that exposes a dashboard

A dashboard earns its keep if it changes what someone does while everything is still fine. So the test is: name the action each panel is meant to drive, and the condition under which someone takes it, before any incident.

Most panels fail the test on inspection. "Requests per second by route" with no threshold and no owner changes nothing when it moves, because nobody has decided what a bad value is or who acts on it. It is a number on a wall. During an incident it is useful as context, but context after the fact is not monitoring, it is archaeology.

Why they get built anyway

The incentives are real and I want to be fair to them.

Dashboards are cheap to make and visible to leadership, so they get made. A wall of graphs reads as maturity in a review, the same way code coverage reads as safety. The cost of a useless dashboard is diffuse and paid later, by the person hunting through forty tabs at two in the morning, while the benefit of making one is immediate and social.

They are also built from availability rather than need. The metric exists, so it gets a panel. Nobody asks what decision it informs, because the question is harder than the click.

The counterargument, honestly

There is a legitimate role for exploratory dashboards. During an incident, having the raw surfaces available speeds diagnosis, and you cannot always predict which slice you will need. I keep a few dense, general dashboards exactly for that, and I am not arguing they should not exist.

The argument is about proportion and labelling. Exploratory surfaces are a reference library. They are not monitoring, and they should not be counted as such, and they should not crowd out the small number of panels that are meant to drive action.

There is also the onboarding value. A new engineer learns a system by staring at its graphs. That is real, and it is also not monitoring. It is documentation wearing a graph's clothes.

What monitoring that works looks like

The teams I have seen get this right share three habits.

Few panels, each with an owner and an action. The production monitoring surface is small, a handful of panels, and each has a named owner and a written sentence: if this crosses that, this person does this. The sentence is the monitoring. The graph is just how you see the condition.

Alerts are the real interface. The thing that wakes someone or opens a ticket is the monitoring. A dashboard without a connected alert or a connected habit is passive. The alert encodes the decision threshold that the dashboard leaves implicit, which is why three metrics that catch incidents argues for a tiny alert set over a broad one.

Dashboards decay on purpose. Panels that nobody has looked at in a quarter get deleted, not archived. The deletion is the feedback loop. A museum that never removes exhibits becomes noise, and noise is what makes the useful panel hard to find at two in the morning.

The uncomfortable conclusion

The number of dashboards is inversely related to the health of your monitoring culture, past a small number. More panels means less attention per panel, which means fewer real decisions, which means the surface exists to be seen, not to be read.

I am not arguing for no visibility. I am arguing that visibility without a decision is scenery, and that the scarce resource in an incident is not data but attention, and a wall of unowned panels spends that attention on numbers that change nothing.

The rule of thumb

For every panel, ask: who acts, and when, if this moves, while things are still fine. If you cannot name them, the panel is decoration, and the honest move is to delete it or attach the sentence that makes it monitoring.

A monitoring surface should be small enough to read in one glance, owned enough that every movement has a responder, and ruthless enough that unused panels die. Everything else is a museum, and museums are for after.

The incident time version of this lesson, where attention is spent well in the first minutes, is the first ten minutes of an incident, and the telemetry purchase version is observability platforms sold you a search engine.

What to do with the forty dashboards you already have

Deleting on principle is satisfying but politically hard, so here is the mechanical version. Export the view counts for every panel over the last quarter. Anything with zero views outside incidents goes into a single "archive" folder, out of the default navigation. You have not deleted anyone's work, you have only stopped it from competing for attention, and the archive becomes the evidence base for the next cleanup.

Then run the action sentence exercise on the survivors. A panel that cannot produce its sentence in a minute of discussion is a candidate for the archive at the next review. Within two quarters you will have a surface small enough to glance, and the glance will mean something again, because meaning was never in the graphs. It was in the agreement about what to do when they move.