30. Observability
1
The picture to keep in your head2
30.1 Why do you need observability?3
30.2 What are the three pillars?4
30.3 What are golden signals, RED and USE?5
30.4 What are SLI, SLO and SLA?6
30.5 What are error budgets?7
30.6 How do you alert without noise?8
30.7 What makes a good dashboard?9
30.8 How do you debug an incident, step by step?10
Memory card and where the analogy breaks11
Practice: five levels12
Interview questions13
Solutions14
Sources15
Code lab30. Observability
30.7 What makes a good dashboard?
3 min read+10 XP
In the car: The speedometer is big and in front of you; the trip computer is a button press away. You don't put the tyre pressure of the spare wheel next to the speedometer.
In the system: Dashboards are for humans under pressure. Make them answer questions quickly:
- Start from the user: a top-level dashboard per user journey (browse, search, checkout) showing the SLIs, error budget remaining and RED metrics.
- Then drill down: per service, then per dependency (payment gateway latency and errors, database pool saturation, queue lag), then per instance.
- Show percentiles, not just averages (30.2.2).
- Mark deploys and config changes on graphs: most incidents start with a change, and a vertical line at "v42 deployed" answers "what changed?" instantly.
- Consistent layout and units across services, so on-call engineers aren't learning a new dashboard at 3 a.m.
- Fewer, better panels. A wall of 80 graphs hides the one that matters.
- Dashboards as code, versioned and reviewed like everything else.
A dashboard is not an alert: nobody watches graphs all day. Alerts tell you when to look; dashboards help you understand what you're looking at.
Memory code: "Speedometer in front, trip computer one press away."