{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"dashboards-people-actually-read","title":"One screen that answers the question","url":"https://addaly.com/learn/cloud-and-shipping/dashboards-people-actually-read","position":23,"of":74,"minutes":8,"answer":"A dashboard is a saved answer to a question somebody asks, so keep three screens (service health, dependencies, business counts) with thresholds drawn on and percentages rather than counts.","keyIdea":"A dashboard is a saved answer to a question somebody asks, so keep three screens (service health, dependencies, business counts) with thresholds drawn on and percentages rather than counts, and never mistake a screen for an alert."},"body":{"format":"markdown","text":"## Most dashboards are decoration\n\nOpen 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.\n\nThe 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.\n\n## Three dashboards, and only three\n\n**1. The service overview: one screen, no scrolling.** Four panels, the same four for every service you will ever run:\n\n- Request rate, split by status class.\n- Error rate, as a percentage of requests, not a raw count.\n- Latency at p50, p95 and p99, on one chart.\n- Saturation: the one resource nearest its limit: database connections in use, queue depth, worker utilisation.\n\nThis is the whole picture of a web service. If those four are healthy, the service is doing its job, whatever the CPU graph says.\n\n**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.\n\n**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.\n\nThat third screen is what catches the outages your monitoring is blind to, and it is the one small teams skip.\n\n## Rules that make a panel readable\n\n- **Put a threshold line on the chart.** A latency graph without the number you consider bad requires the reader to remember it.\n- **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.\n- **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.\n- **Percentages, not counts, for errors.** Fifty errors is meaningless without the denominator.\n- **No stacked area charts for latency.** Percentiles do not add up, and stacking implies they do.\n- **Name each panel as a question**: \"Are we serving errors?\" beats \"http_requests_total by status\".\n\n## Colour\n\nAbout 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.\n\n## Do not put the dashboard on the critical path\n\nTwo failures worth planning around:\n\n- **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`.\n- **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.\n\n## The free path\n\nGrafana, 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.\n\nAnd 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.\n\n## The test\n\nShow 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."},"check":{"question":"Your overview dashboard shows normal traffic, sub-1% errors and flat p95 latency, but signups have been zero for three hours. Which design decision would have surfaced this soonest?","options":[{"text":"Adding CPU and memory panels for every instance","correct":false,"tempting":"Resource panels describe the machine, not the outcome; a validation bug that rejects every form uses less CPU, not more."},{"text":"Alerting on p99 latency instead of p95","correct":false,"tempting":"A finer latency percentile finds slow requests, but these requests are fast: they are fast failures that return 200."},{"text":"Tracking a business counter such as completed signups alongside the technical panels","correct":true},{"text":"Splitting the error-rate panel by endpoint","correct":false,"tempting":"Useful once errors exist, but the failure here produces successful responses, so no error panel of any granularity shows it."}]},"prev":{"slug":"metrics-that-mean-something","title":"Four numbers that describe any service","url":"https://addaly.com/learn/cloud-and-shipping/metrics-that-mean-something"},"next":{"slug":"errors-that-find-you","title":"Errors that come to you","url":"https://addaly.com/learn/cloud-and-shipping/errors-that-find-you"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'One screen that answers the question', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/dashboards-people-actually-read (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"One screen that answers the question","courseTitle":"Shipping It","module":{"index":3,"slug":"knowing-what-it-is-doing","title":"Knowing what it is doing"},"answer":null,"keyIdea":"A dashboard is a saved answer to a question somebody asks, so keep three screens (service health, dependencies, business counts) with thresholds drawn on and percentages rather than counts, and never mistake a screen for an alert.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"most-dashboards-are-decoration","runs":[{"text":"Most dashboards are decoration"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"three-dashboards-and-only-three","runs":[{"text":"Three dashboards, and only three"}]},{"t":"p","runs":[{"text":"1. The service overview: one screen, no scrolling.","b":true},{"text":" Four panels, the same four for every service you will ever run:"}]},{"t":"ul","items":[[{"text":"Request rate, split by status class."}],[{"text":"Error rate, as a percentage of requests, not a raw count."}],[{"text":"Latency at p50, p95 and p99, on one chart."}],[{"text":"Saturation: the one resource nearest its limit: database connections in use, queue depth, worker utilisation."}]]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"2. The dependency screen.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"3. The business screen.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"That third screen is what catches the outages your monitoring is blind to, and it is the one small teams skip."}]},{"t":"h2","id":"rules-that-make-a-panel-readable","runs":[{"text":"Rules that make a panel readable"}]},{"t":"ul","items":[[{"text":"Put a threshold line on the chart.","b":true},{"text":" A latency graph without the number you consider bad requires the reader to remember it."}],[{"text":"Same time range everywhere on the screen","b":true},{"text":", and default it to the last six hours, not the last hour. A spike is only obvious against yesterday."}],[{"text":"Compare with the previous week","b":true},{"text":" on the traffic panel. Every consumer service has a weekday shape, and “low” on Sunday morning is not an incident."}],[{"text":"Percentages, not counts, for errors.","b":true},{"text":" Fifty errors is meaningless without the denominator."}],[{"text":"No stacked area charts for latency.","b":true},{"text":" Percentiles do not add up, and stacking implies they do."}],[{"text":"Name each panel as a question","b":true},{"text":": “Are we serving errors?” beats “http_requests_total by status”."}]]},{"t":"h2","id":"colour","runs":[{"text":"Colour"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"do-not-put-the-dashboard-on-the-critical-path","runs":[{"text":"Do not put the dashboard on the critical path"}]},{"t":"p","runs":[{"text":"Two failures worth planning around:"}]},{"t":"ul","items":[[{"text":"Your dashboard runs on the infrastructure it is watching.","b":true},{"text":" 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 "},{"text":"journalctl","code":true},{"text":"."}],[{"text":"The dashboard is not an alert.","b":true},{"text":" 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."}]]},{"t":"h2","id":"the-free-path","runs":[{"text":"The free path"}],"role":"free"},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-test","runs":[{"text":"The test"}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"Your overview dashboard shows normal traffic, sub-1% errors and flat p95 latency, but signups have been zero for three hours. Which design decision would have surfaced this soonest?"}],"options":[{"text":[{"text":"Adding CPU and memory panels for every instance"}],"correct":false,"tempting":[{"text":"Resource panels describe the machine, not the outcome; a validation bug that rejects every form uses less CPU, not more."}]},{"text":[{"text":"Alerting on p99 latency instead of p95"}],"correct":false,"tempting":[{"text":"A finer latency percentile finds slow requests, but these requests are fast: they are fast failures that return 200."}]},{"text":[{"text":"Tracking a business counter such as completed signups alongside the technical panels"}],"correct":true,"tempting":null},{"text":[{"text":"Splitting the error-rate panel by endpoint"}],"correct":false,"tempting":[{"text":"Useful once errors exist, but the failure here produces successful responses, so no error panel of any granularity shows it."}]}],"order":[1,3,0,2],"why":null},"prev":{"slug":"metrics-that-mean-something","title":"Four numbers that describe any service","minutes":9},"next":{"slug":"errors-that-find-you","title":"Errors that come to you","minutes":8}}}