The Dashboard Nobody Opens

Failed measurement programmes rarely announce themselves. The tooling works, the data is accurate, the dashboard renders. It just stops being opened, and eighteen months later someone questions the renewal and nobody can name a decision it informed.

This is the most common outcome in this category, and it's a design failure rather than a tooling one.

Why it happens

The dashboard lives where nobody goes. The classic version is a platform team standing up Apache DevLake, building Grafana dashboards, writing per-team SQL filters, wiring authentication — and then discovering developers don't open Grafana. Every organisation doing this built the same thing, and every one of them hit the same wall. The historical workaround was embedding iframes or building a portal plugin, which is more maintenance surface for the same problem.

No decision was attached. If nobody wrote down what would change based on the numbers, the dashboard is a status display. Status displays get checked twice and then never again, because nothing depends on them.

It shows everything. Platforms ship with default dashboards designed to demo well, which means comprehensive. A screen with twenty tiles has no focus, and a reader with no focus doesn't return.

The numbers never move in a way that means anything. Metrics reported as monthly averages across a whole organisation are stable by construction. If a chart looks the same every week, people correctly stop looking at it.

It answers a question nobody asked. The buying failure and the usage failure are the same failure, discovered at different times.

The diagnostic

Three questions, answerable in a minute.

When did this dashboard last change someone's mind? If you can't name an instance in the last quarter, it isn't working.

Who opened it this week, without being asked? Voluntary usage is the only usage that counts. A number reviewed only because it's on a meeting agenda is a ritual.

If it disappeared tomorrow, what decision would get worse? If the answer is none, you have your answer.

Fixes that work

Move it to where people already are. This is the highest-leverage change and the most often skipped. Metrics surfaced in the developer portal, the pull request, or a weekly message land differently from metrics behind a separate login.

It got materially easier in 2026: a DevLake-to-DORA backend module contributed to Backstage's community plugins bridges DevLake's metrics API into the standard DORA plugin and puts deployment frequency, lead time, change failure rate and recovery time on every service's catalog page. If you run Backstage — and adoption is substantial — the wiring platform teams used to build by hand is now the part they skip.

Cut to three numbers. One per question you actually have. Everything else goes to a second page nobody needs to see. A dashboard that fits in one glance gets glanced at.

Push instead of pull. A short weekly or fortnightly message with the two or three numbers and a sentence on what changed beats any dashboard, because it arrives rather than waiting. Most teams that get value from metrics do this and treat the dashboard as the place you go when the message raises a question.

Report deltas and distributions, not levels. "Median review wait went from 6 hours to 19 over three weeks" is a reason to look. "Median review wait: 19 hours" is wallpaper. Include p75 and p90 — the tail is where the actionable problems live.

Attach an owner and a decision to each metric. If a number moves, someone specific investigates. A metric with no owner is decoration.

Delete on a schedule. Every quarter, remove anything that hasn't informed a decision. This is the single habit that separates working programmes from accumulating ones, and most dashboards in this category could lose half their tiles without losing anything.

The uncomfortable version

Sometimes the dashboard isn't being ignored because it's badly designed. Sometimes it's being ignored because the organisation isn't willing to act on what it says.

If the data has shown for three quarters that review capacity is the constraint and nothing has been funded, people stop looking — correctly. The dashboard has become a record of a problem nobody intends to solve, and continuing to check it is just a reminder.

That's not a measurement problem, and no tool fixes it. The honest move is to either escalate the finding properly or stop measuring the thing, because a metric that documents an unfixable problem is worse than no metric: it burns the credibility of the whole programme.

Frequently asked

Should we cancel the tool if nobody uses it? Usually yes, and the money is not the main reason. An unused measurement programme makes the next one harder, because people remember the last one.

Is a weekly message really better than a dashboard? For most teams, yes. Push beats pull for anything you want people to notice. The dashboard remains useful as the place to investigate once something has prompted a question.

How many metrics is too many? More than five on a screen anyone is expected to read regularly. Teams tracking fifteen are producing a report for an audience that doesn't exist.

What if leadership wants the comprehensive view? Give them a separate quarterly report. That's a different artefact for a different audience, and merging the two produces something that serves neither.