One screen that answers the question

Most dashboards are decoration

Open the monitoring of almost any small project and you find a wall of forty graphs: CPU per core, memory, disk, network in and out, garbage collection pauses, a pie chart of HTTP methods. During an incident nobody looks at it. During normal weeks nobody looks at it either.

The reason is that it was built from what the tool could draw rather than from a question somebody actually asks. A dashboard is a saved answer. If you cannot name the question, delete the panel.

Three dashboards, and only three

1. The service overview: one screen, no scrolling. Four panels, the same four for every service you will ever run:

• Request rate, split by status class.
• Error rate, as a percentage of requests, not a raw count.
• Latency at p50, p95 and p99, on one chart.
• Saturation: the one resource nearest its limit: database connections in use, queue depth, worker utilisation.

This is the whole picture of a web service. If those four are healthy, the service is doing its job, whatever the CPU graph says.

2. The dependency screen. One row per external thing you call: your database, your mail provider, your payment provider, your model API. Rate, error rate, and latency for each. This exists to answer “is it us or them” in five seconds, which is the second question in most incidents and the one that most often goes unanswered for twenty minutes.

3. The business screen. Signups, posts, orders, messages sent: the counts that mean the product is working. Keep it because technical health can be perfect while the thing is broken: a form that fails validation for everybody produces a beautiful graph of fast 200s.

That third screen is what catches the outages your monitoring is blind to, and it is the one small teams skip.

Rules that make a panel readable

• Put a threshold line on the chart. A latency graph without the number you consider bad requires the reader to remember it.
• Same time range everywhere on the screen, and default it to the last six hours, not the last hour. A spike is only obvious against yesterday.
• Compare with the previous week on the traffic panel. Every consumer service has a weekday shape, and “low” on Sunday morning is not an incident.
• Percentages, not counts, for errors. Fifty errors is meaningless without the denominator.
• No stacked area charts for latency. Percentiles do not add up, and stacking implies they do.
• Name each panel as a question: “Are we serving errors?” beats “http_requests_total by status”.

Colour

About one in twelve men has a form of red-green colour blindness. A dashboard whose only signal is red versus green is unreadable to somebody on your team or in your audience. Use position, shape and text as well as colour: the number in the corner, the threshold line, the word “degraded”. This is the same accessibility rule as everywhere else, and dashboards break it more often than product pages do.

Do not put the dashboard on the critical path

Two failures worth planning around:

• Your dashboard runs on the infrastructure it is watching. If Grafana is on the same box as the app, a full disk takes both. Host monitoring somewhere else, or accept that during the worst incidents you are back to journalctl.
• The dashboard is not an alert. Nobody is looking at 3am. A screen answers “what is happening now that I already know something is wrong”; a page answers “wake up”. Confusing the two is how teams end up staring at graphs all day and still missing the outage.

The free path

Grafana, self-hosted or on its free cloud tier, with Prometheus for metrics, is the standard free stack and the one most job ads name. Netdata gives you a decent machine-level dashboard with a single install command. Your cloud provider’s built-in dashboards are free and usually enough for the overview screen.

And the smallest honest version: a single page in your own app, behind admin authentication, that prints ten numbers from ten SQL queries. It costs an afternoon, requires no new infrastructure, and for a project with a hundred users it will tell you more than any generic template.

The test

Show the overview screen to somebody who does not work on the service and ask: is it healthy, and how do you know. If they have to ask which line matters, the dashboard is not finished.