Most Grafana dashboards get built once, admired once, and never opened again. That’s usually because they have forty panels and answer zero questions. A dashboard someone actually reads during an incident has four panels, maybe six, each answering something specific.

The questions a dashboard should answer

Before adding a panel, ask what question it answers. If you can’t say it in one sentence, don’t add it. For a typical web service, four questions cover almost every real incident:

1. Are we getting traffic? (requests per second)
2. Are requests failing? (error rate)
3. Are requests slow? (latency, p95 not average)
4. Is the box running out of room? (CPU, memory, disk — saturation)

This is the RED method (Rate, Errors, Duration) for services, plus a saturation panel borrowed from Google’s USE method. You don’t need to memorize the acronyms — just build panels that answer those four things.

Panel 1: Request rate

sum(rate(http_requests_total[5m]))

A line graph over time. This tells you “is traffic normal” at a glance — a flat line at zero after a deploy means something’s badly wrong before you even look at errors.

Panel 2: Error rate, as a percentage

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Not error count — error rate. 50 errors out of 100 requests and 50 errors out of 100,000 requests are very different incidents, and a count-only panel can’t tell you which one you’re in.

Panel 3: p95 latency, not average

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Average latency hides the problem. If 95% of requests take 50ms and 5% take 8 seconds, the average looks fine while a real slice of your users are having a bad time. p95 (or p99 if you serve enough traffic to make it meaningful) surfaces that.

Panel 4: Saturation

CPU, memory, and disk usage on the host, from node_exporter:

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

This is the panel that tells you why the other three are degrading — not just that something’s wrong, but whether the box is out of headroom.

What to leave out

If you want per-endpoint or per-route detail, put it on a second dashboard you link to, not on the one you open first during an incident.

Dashboards vs. alerts

A dashboard is for humans looking at it on purpose. If a number matters enough that someone needs to know the moment it crosses a threshold, that’s an alert, not a panel — don’t rely on someone noticing a graph creeping up at 2am.

Four panels that map to real questions beat forty that map to “this metric existed and I had room.” Build the four, use them during your next incident, and only add a fifth when you catch yourself wishing it existed.