I’ve built dashboards for a lot of organizations. The modal outcome is a dashboard that gets shown during the implementation demo, gets mentioned as an achievement in the quarterly review, and then sits unvisited because nobody on the team has incorporated it into their actual decision-making.
The failure mode is almost always the same: the dashboard was built around what data is available rather than what questions need to be answered. It displays the metrics that were easy to collect rather than the metrics that matter. It’s built as a deliverable, not as a tool.
Building dashboards that people actually use requires starting from the opposite direction: what decisions does someone need to make, and what information would change their decision?
The Decision-First Design Process
Before opening Grafana or any other visualization tool, answer these questions in writing:
- Who uses this dashboard? Name a specific person or a specific role.
- What decision does this dashboard inform? Be concrete — “should we page the on-call engineer?” is a decision, “system health” is not.
- What’s the ideal scenario where this dashboard is consulted? A morning review? During an active incident? Before a capacity planning meeting?
- What would someone do differently if they had this dashboard vs. not having it?
If you can’t answer question 4, you probably don’t need the dashboard. The absence of a clear answer is a signal that the proposed dashboard is informational rather than operational — it tells people things without changing what they do.
Operational vs. Analytical Dashboards
The distinction that determines design choices:
Operational dashboards are used in real-time or near-real-time to drive operational decisions. The canonical example: a service health dashboard used by an on-call engineer during an incident. The design requirements: fast to read (seconds, not minutes), clear status indication (green/yellow/red), focused on the question “is something wrong and where?” The information density is lower; the signal clarity is higher.
Analytical dashboards are used in longer decision cycles — weekly planning reviews, capacity planning, trend analysis. They can carry more information density because the viewer has time to explore. They work better as interactive tools with filtering and drill-down than as static displays.
Building an analytical dashboard and expecting it to be useful for operational decisions is one of the most common dashboard failures. The on-call engineer at 3 AM does not want interactive filtering and twelve trend lines. They want a clear signal: where is the problem?
What to Put on a Dashboard (and What Not To)
Every metric on a dashboard should pass a filter: does this metric tell me something I’d act on if it were outside normal range?
The metrics that pass the filter for a typical production service:
- Error rate — directly actionable. An error rate spike means investigate immediately.
- Latency at P95 and P99 — the tail latency your worst-served users experience. A P99 spike often precedes incidents.
- Request throughput — combined with error rate and latency, tells you whether the service is handling its expected load.
- Database connection pool saturation — a leading indicator of database-related availability issues.
- Queue depth (for async systems) — growing queue depth means processing can’t keep up with input.
Metrics that feel important but rarely change what you do:
- CPU utilization for well-scaled systems — if you’ve auto-scaled correctly, CPU is managed. Watching it is informational.
- Total request count (without normalization) — grows with traffic but doesn’t tell you anything about service health independently.
- Memory usage without trend context — a snapshot of memory usage is meaningless without knowing what normal looks like.
The test: look at a metric on the dashboard and ask “if this went up or down by 20%, what would I do?” If the answer is “investigate further” for every possible movement, the metric is too coarse. If the answer is “nothing specific,” it probably shouldn’t be on an operational dashboard.
Time Window Choices Matter More Than They Should
The default Grafana time window is “last 6 hours” or “last 24 hours.” For most operational dashboards, this is wrong.
The right time window for an incident dashboard: the last hour, with the ability to zoom in to the last 15 minutes. Context from 6 hours ago is rarely useful when you’re investigating an active incident.
The right time window for a daily review dashboard: the last 7 days with hourly granularity. This shows weekly patterns — the Monday morning traffic spike, the weekend low — that the last 24 hours hides.
The right time window for a capacity planning dashboard: 90 days with daily granularity. Capacity planning decisions are based on growth trends that require weeks of history to be meaningful.
Dashboard templates in Grafana support multiple linked time ranges, which lets you have a quick-look panel at 1-hour granularity alongside a trend panel at 30-day granularity. Use this for dashboards where both operational context and trend context are relevant.
Dashboard Infrastructure: Don’t Skip This
The dashboard is only as good as the data feeding it. Before worrying about visualization, answer:
- Is the data collected consistently? Gaps in metric collection create gaps in the dashboard — which look like incidents and trigger false alarms.
- Is the data queryable with acceptable latency? A dashboard that takes 30 seconds to load is a dashboard nobody uses.
- Is there labeling/tagging that enables filtering? Dashboards for a single service are easy. Dashboards that need to slice by service, environment, region, or team require consistent tagging on all metrics.
- Is alert data linked to dashboard data? When an alert fires, can the on-call engineer click from the alert to the relevant dashboard panel? If not, you’ve created two separate systems that require manual correlation.
Prometheus and Grafana together are the most common open-source observability stack, and they handle all of these requirements well when set up correctly. DataDog is the managed alternative with better out-of-the-box integration but significant per-host licensing cost. The choice between them is a cost/operational overhead tradeoff, not a capability tradeoff for most use cases.
The Dashboard Audit
If you have existing dashboards that you suspect aren’t being used effectively, the simple audit:
- Check the access logs for each dashboard. How often is it viewed? By whom? When?
- Talk to the people who are supposed to be using it. Do they actually use it? What’s missing?
- For each panel, ask the decision-first question: what would you do differently if this metric changed?
The audit typically surfaces a large number of dashboard panels that are unused and a small number that are critical. Consolidate the critical ones into a single well-designed dashboard and deprecate the rest. A smaller number of well-designed dashboards is always better than a large collection of rarely-used ones.
Our data engineering and analytics practice builds dashboards as part of broader observability infrastructure. The design conversation happens before the implementation. Related: if your dashboards need to inform AI/ML operations, the metrics for model performance and data pipeline health have distinct design requirements worth considering separately from general service observability.