The Dashboard Nobody Opens
Text
1. The claim
Observability is usually built bottom-up. A library emits what it can, a platform team collects it, and a dashboard is assembled from what arrived. Every panel on that dashboard is true. The collection is complete, the queries are correct, the alerting is wired. And during the incident, the on-call engineer opens it, looks at it for four seconds, and goes to the logs.
That four seconds is the measurement that matters and nobody records it. A dashboard’s value is not the number of signals it displays. It is the number of triage questions it answers without a follow-up query.
2. Why bottom-up construction fails
The signals that are cheapest to emit are properties of components. The questions that matter are properties of the interaction between components and users. These are different objects, and no amount of correct aggregation turns one into the other.
emitted (cheap) asked (expensive)cpu, memory, disk is it me or them? request rate all users or some? error count did it start with a deploy? p50 / p95 / p99 is it getting worse? queue depth what breaks next?
The right-hand column is answerable from the left-hand column, and that is exactly the problem: it is answerable by an engineer doing arithmetic and correlation in their head, under time pressure, with a pager going off. The dashboard has delegated the hard part.
3. The five questions
These are the questions I have watched people ask, in this order, in every triage I have been part of. Any dashboard that does not answer them is decoration.
| § | Question | What the panel must show |
|---|---|---|
| 1 | Is it us or a dependency? | Error rate split by originating layer, with dependency errors attributed to the dependency rather than counted as ours. |
| 2 | Everyone or some? | The same failure rate broken by tenant, region and client version, on one view. This is the panel that most often does not exist, because the dimension was never emitted. |
| 3 | Did it start with a change? | Deploy and configuration-change markers on the same time axis as the failure. A separate deploy dashboard does not count; correlation across two browser tabs is the work being avoided. |
| 4 | Is it getting worse? | Rate of change, not level. A flat 4% error rate and a 4% rate doubling every two minutes look identical on a gauge and require opposite responses. |
| 5 | What fails next? | Saturation of the things that will queue: pools, buffers, budgets. Including the retry budget, which is the signal from 5.6 that almost nobody emits. |
4. The construction rule, and the test
4.1. One view per question, named after the question. Not “Service Health”. The panel title is the interrogative sentence. This reads as unserious and it is the single change with the largest effect, because it makes an unanswerable question visibly unanswered rather than quietly absent.
4.2. If a signal answers no question, it is not on a dashboard. Keep emitting it, keep it queryable, keep it out of the view. Storage is cheap and attention is not.
4.3. Instrument the dashboards themselves. Most observability stacks can report which views were opened and when. A dashboard with no opens in ninety days is either wrong or redundant, and in both cases deleting it is an improvement. This is the only part of the paper with a direct measurement attached, and it is the part teams resist most.
4.4. The ninety-second test. Take an engineer who has been on-call for under a month. Give them a real past incident. They should answer all five questions in ninety seconds without asking anyone. If they cannot, the gap is a work item with an owner, and the dashboard is the deliverable, not the diagnosis.
Figure 2. How often each question is already answered, ranked from the systems I have reviewed. A ranking from memory, not a survey.
5. The strongest objection
6. What this paper does not claim
Component metrics are necessary. Questions 1 and 5 are answered from them, and a system that does not emit them cannot answer either. The five questions are not a complete set; they are what has been sufficient for first-response triage in the systems I have run.
Dashboards do not cause slow incident response. The claim is smaller and more specific: a dashboard assembled from what was easy to emit is answering a question nobody asked, and that cost stays invisible because almost nobody measures whether it was opened.
Retirement conditions
This paper MUST be retracted if any of the following is demonstrated.
| § | Condition |
|---|---|
| 1 | A team whose dashboards are built from emitted signals rather than from operator questions, and whose new on-call engineers nonetheless answer the five triage questions in Section 3 within ninety seconds, without assistance, on an incident they have not seen before. |
| 2 | Evidence that question-driven dashboards measurably slow diagnosis of novel failure modes, so that the breadth they discard costs more than the speed they buy. |
| 3 | Query-side tooling that makes ad-hoc exploration fast enough that pre-built views stop mattering, at which point this paper is about a tool generation rather than about a practice. |
Revision history
| Date | Change |
|---|---|
| 2026-08-14 | Text written: why bottom-up construction fails, the five triage questions, the construction rule and the ninety-second test, and the over-fitting objection. Retirement conditions added. Confidence unchanged. |
| 2025-06-05 | Listed in Section 5 with a title, a summary and a confidence value. No text. |