Open your Grafana instance and look at the list. Not the two or three you actually use. The whole list.

Most of those panels have an origin story, and it is nearly always the same one. Something broke, nobody could see it while it was happening, and the postmortem produced an action item that read "add a dashboard for X". Somebody did. The panel has been there ever since, quietly rendering, occasionally loading slowly, watched by nobody.

That is not a criticism of the practice. It is a reasonable thing to do after an incident. But it means your dashboard collection is not a picture of your system. It is an archive of questions your team has already been forced to ask.

Which explains rather a lot about why incidents still feel the way they do.

The archive is excellent at repeats

A dashboard built after an incident is perfectly tuned for that incident recurring. If the same failure mode returns, you will spot it in seconds, because somebody already did the hard thinking about what to plot and where.

Novel failures get none of that benefit. The question you need to ask at two in the morning is, by definition, one nobody anticipated, and there is no panel for it. So you fall back to the thing every engineer does: open a terminal, write a query by hand, and start reconstructing.

Recent analysis of the 2026 observability landscape puts diagnosis at twenty to thirty minutes even in well-instrumented systems, and makes the point that the delay is not caused by missing data. The data is there. The system simply does not explain itself, so an engineer has to move between dashboards, logs, traces and deploy history and assemble the explanation manually.

The survey data agrees. The Grafana Labs annual observability survey, drawing on 1,363 responses from engineers, SREs and technology leaders across 76 countries, found complexity and overhead at the top of observability concerns for 2026 at 38%, ahead of signal-to-noise at 34% and cost at 31%. LogicMonitor's 2026 outlook found only 41% of IT leaders satisfied with their tools' ability to produce information they can act on, and identified the delay as sitting in interpretation rather than detection.

We solved seeing. We did not solve asking.

Ten engineers, four answers

There is a second-order problem that shows up once the collection gets large enough.

A recent piece on telemetry debt describes it precisely: ask ten engineers which dashboard is the authoritative one for checkout latency and you will get four different answers, plus at least one dashboard quietly disagreeing with the others because it queries a different aggregation window that nobody documented.

Half of them were built for a single postmortem and never revisited. Ownership is untracked. During an incident, different people are looking at different numbers and reaching different conclusions, and a good chunk of the first ten minutes goes on establishing which screen to believe.

Adding more panels does not fix this. It is the mechanism that produced it.

The valuable part is not the picture

Here is the shift that changed how I think about this.

The chart is the least interesting thing on a dashboard panel. The valuable part is the query underneath it, because that query is a piece of institutional knowledge somebody worked out and then wrote down.

When an engineer built a panel showing error rate for a service, they made a series of decisions. Which metric actually represents failure here. Whether to count 5xx only or include timeouts. What window smooths the noise without hiding a spike. Which labels to group by. Those decisions took real effort and real familiarity with the service, and they are now sitting in a PromQL expression that almost nobody ever reads.

Your dashboards are your organisation's working definition of healthy, written in a language a machine can execute. They are just presented as pictures, which makes them look like output rather than knowledge.

Reading the queries, not just the panels

This is where Vörr comes in, and I should say I work at Frigga and Vörr is our product, so read accordingly.

When Vörr connects to Grafana, it does not screenshot your dashboards or try to interpret the visualisations. It reads each dashboard's panels along with the raw query behind every one of them, and the datasource each query runs against. That means it can pick up how your team defines healthy for a given service rather than imposing a generic definition, and it can re-run a specific panel's query over whatever window you care about without anybody rewriting the expression.

That last part matters more than it sounds. Reusing your exact query means the number you get back is the same number your team has been reasoning about for two years, aggregation window and all. A tool that invents its own definition of error rate produces a figure that is defensible in isolation and useless in an argument.

The other half is being able to ask something nobody built a panel for. Raw PromQL and LogQL queries go straight through, so the novel question at two in the morning does not require finding the right dashboard first. It requires knowing what you want to know.

None of this replaces your dashboards. It reads them, treats them as the accumulated knowledge they are, and removes the constraint that you can only ask questions somebody thought of in advance.

What I would do with the archive

Stop treating dashboard count as a maturity signal. It is closer to a record of how many times you have been surprised.

Do not mass-delete, though. The instinct after reading anything about dashboard sprawl is to run a cull, and you will throw away encoded knowledge that took years to accumulate. The queries are worth more than the panels.

Mark a small set as authoritative, per service, and say so somewhere findable. Four dashboards that everyone agrees on beat forty that nobody can rank. If two panels claim to show the same thing and disagree, that is not a display problem, it is two teams using different definitions, and that is worth resolving before the next incident rather than during it.

Then check whether your team can ask a question that nobody pre-built. Not whether the data exists, because it almost certainly does. Whether someone on call at three in the morning can get an answer out of it without knowing which dashboard to open. If the honest answer is that they need to find the right panel first, then your visibility is fine and your ability to investigate is limited to the questions you have already been asked.

Incidents do not repeat politely. The next one will ask something new, and it will not check whether you built a panel for it.

Author note

I am Mohan Gopi, an Associate DevOps Engineer at Frigga Cloud Labs, where I work on Vörr, connecting code, cloud, and monitoring so that a question can be answered from the state of a system rather than from a guess. I wrote this because dashboard count gets treated as evidence of observability maturity when it is closer to a scar count. The pattern I keep seeing is teams responding to a slow investigation by building another panel, which helps precisely once, the next time that exact failure returns. Read as an archive, your dashboards will tell you what your system has already done to you and what your team learned from it, which is genuinely valuable. Read as coverage, they will convince you that you can see everything, right up until something asks a question nobody wrote down.

Let us connect on LinkedIn → Mohan Gopi

Every Dashboard Is a Question Somebody Asked Once