How I build dashboards that product and engineering can actually use together.
Every company I've worked at has had that one dashboard. You know the one. Fifty panels, a wall of green, and if you ask who owns it, nobody seems to remember. It was useful in 2021. Maybe.
The problem isn't that the dashboard is wrong. The problem is that it was built for a different question than the one the team is asking today. Observability decays. If you don't curate it, it becomes wallpaper — technically there, not actually read.
Here's how I try to build dashboards that survive.
Every graph should answer a decision
The test I put to every panel is simple: "If this graph changes, what will I do differently?"
If I can't answer that, the graph gets cut. No exceptions. A dashboard isn't a museum of metrics — it's a tool for making decisions, and every panel that doesn't support a decision is stealing attention from the ones that do.
This sounds harsh, but it's freeing. Once you apply it, you stop feeling guilty about deleting old panels, because you're not losing information — you're removing noise that was hiding the signal.
Tie technical traces to user intent
One of the best shifts I've made in the last couple of years is instrumenting key user journeys as first-class spans. Not "POST /api/checkout" but "user_checkout" — a trace that starts when the user clicks, flows through every service the request touches, and ends when they see confirmation.
The difference isn't technical. It's cultural. When your spans are named after user intents, product managers can actually read your traces. You stop having "engineering investigated the issue" and start having "engineering and product looked at the same trace together and figured out where the flow was breaking." That shift turns observability from a back-office tool into a shared language.
Alert on symptoms, not everything
The other place dashboards go wrong is trying to double as alert configuration. They're not the same tool.
A good alert rule is about user impact: error rates climbing, latency over a threshold, conversion dropping sharply. A dashboard panel can show fifteen different flavors of internal metric that are interesting to look at but not urgent enough to wake somebody up for.
Mixing the two is how you end up with an on-call rotation drowning in low-signal pages. Separate "what should I look at when I'm investigating" from "what should interrupt my dinner." Treat them differently.
Make them easy to throw away
The dirty secret of good dashboards is that the best ones are usually the newest. That doesn't mean the team is constantly starting from scratch — it means they're not afraid to delete the ones that stopped being useful.
Build dashboards as a product. Name them, own them, review them quarterly, retire the ones nobody uses. An observability stack without that kind of hygiene turns into the same graveyard of panels every team eventually has, where nobody quite remembers what any of it means.
You deserve better telemetry than that. So do your users.
