Every analytics team has one. A dashboard that took three weeks to build, got a nice reception in the demo, and now gets opened twice a month, both times by the person who built it, checking whether it still loads.
I have built a few of these. The uncomfortable part is that they were not bad dashboards. The charts were correct, the data was clean, the filters worked. They were just never going to be used, and the reasons had almost nothing to do with the things I spent my time on.
Here is what I have learned about why dashboards die, in rough order of how often it happens.
1. It answers a question nobody was asking
The single biggest cause. Someone asks for “a dashboard for sales performance” and you build a dashboard for sales performance. Twelve charts covering revenue, volume, region, product mix, trend lines, the lot.
But the person asking had one actual question in their head, something like “am I going to miss my quarterly target, and if so, where is the gap.” You gave them twelve answers, one of which is theirs, and they have to find it every time.
The fix is boring and works: before building anything, ask what decision this dashboard supports. Not what data they want to see. What they will do differently depending on what it shows. If there is no answer, or the answer is “just to have visibility”, you are building a report nobody reads.
The follow-up question is even better: what will you do if this number is bad? If nobody can answer that, the number does not need a dashboard.
2. It is slow
People are more sensitive to dashboard latency than they will ever admit in a meeting. A dashboard that takes fifteen seconds to load gets opened. A dashboard that takes fifteen seconds every time a filter changes gets abandoned within a fortnight.
The pattern is predictable. The user clicks a filter, waits, gets impatient, clicks something else before the first query returns, gets a confusing state, and concludes the dashboard is broken. They do not file a ticket. They just stop coming back.
What usually causes it:
Querying raw transactional tables. Your dashboard should almost never hit the same tables your application writes to. Build a reporting layer, even a simple one. A nightly materialised table that pre-aggregates to the grain your charts need will outperform any amount of query tuning on the raw data.
Computing the same thing in every chart. If eight charts each independently calculate “active users this month” with slightly different SQL, you have eight slow queries and eight chances to disagree with each other. Compute it once.
No filtering on the partition or index column. A date filter that the database cannot use to skip data is not a filter, it is decoration. Check that your filter columns are actually indexed or partitioned, and that the filter is being pushed down rather than applied after a full scan.
Unbounded default views. If the dashboard opens showing all time by default, every user pays the cost of the largest possible query before they narrow anything down. Default to the last 30 days. Let people widen it deliberately.
3. Two charts disagree and nobody trusts it anymore
This one is fatal, and it happens quietly.
A manager notices that the revenue number on the summary card does not match the sum of the revenue bar chart below it. Maybe one excludes cancelled orders and the other does not. Maybe one uses order date and the other uses payment date. Both are defensible. Together they are a credibility problem.
Once someone catches a contradiction, they stop trusting every number on the page, including the correct ones. And they tell other people. You cannot recover from this by fixing the one chart, because the trust was in the dashboard as a whole.
Prevention is the only real cure. Define your metrics once, in one place, as a view or a semantic layer, and have every chart read from it. If “active user” means something specific, it should be impossible for two charts to mean different things by it, because there is only one definition to reference.
When someone asks for a metric that differs subtly from an existing one, push back and find out whether they need a genuinely new metric or just a filter on the existing one. Usually it is the second.
4. Nobody knows what the numbers mean
You know that “completion rate” excludes sessions shorter than 30 seconds because of that bot traffic issue in March. The person reading the dashboard does not. They will either assume it means something simpler than it does, or notice it looks odd and quietly stop relying on it.
Definitions need to live next to the numbers, not in a document. A short description under each chart. A tooltip on the metric name. Anything that survives the reader not having been in the original meeting.
This gets worse over time, not better, because the people who understand the caveats move to other teams and the dashboard outlives their institutional memory.
5. It shows numbers without context
A chart that says “conversion rate: 3.2%” tells you nothing. Is that good? Better than last month? Better than target?
Almost every number worth displaying needs a comparison to be readable: versus previous period, versus target, versus the same period last year, or versus another segment. Without one, the reader has to supply the context from memory, and they will not.
This is also the difference between a dashboard that people scan in ten seconds and one they have to study. If the good and bad states are visually obvious, they will actually look at it daily. If they have to interpret, they will look at it when someone asks them to.
6. There is no owner
Dashboards rot. A column gets renamed upstream, a filter starts returning nothing, a data source changes its refresh schedule. If nobody owns the dashboard, these break silently and the first person to notice concludes it is unreliable.
Every dashboard that matters needs a name attached to it and a basic check that it is still correct. Even something crude helps: a hidden chart showing row counts by day, so a drop to zero is visible. A last-refreshed timestamp on the page so users can see for themselves whether the data is current.
And dashboards that stop mattering should be deleted. A workspace with 200 dashboards, 180 of them stale, actively damages trust in the 20 that are good, because users cannot tell which is which.
What good looks like
The dashboards I have built that survived have a few things in common, and none of them are technical.
They answer one question clearly, at the top, in large type, with a comparison. Everything else on the page exists to explain that number when it looks wrong.
They load in under three seconds on the default view.
They have fewer charts than the first draft did. Usually about half.
Someone owns them, and that person hears about it when they break.
And critically, they were built with the person who was going to use them sitting there, not from a requirements document. The single highest-value hour in dashboard work is watching someone use the first version. You learn more in that hour than in a week of building, mostly about which of your careful design decisions they did not notice at all.
The uncomfortable conclusion
Most of the skill in dashboard work is not chart design or SQL optimisation. It is figuring out what question someone is really asking, which is a conversation problem rather than a technical one.
That is frustrating if you enjoy the technical part, which most of us do. But it explains why two analysts of equal technical skill can produce work with wildly different impact, and it is the thing most worth getting better at.
The good news is that it is learnable, and the feedback loop is fast. Ask what decision this supports. Ask what they will do if the number is bad. Then build the smallest thing that answers it, and watch someone use it.