Demo type · 11

Status report

Use this when the reader needs to read the current state of a system at a glance — what is healthy, what is moving the wrong way, and what just broke.

This is a copyable exemplar. Lift the <section id="demo-stage"> block into a lesson built from assets/lesson-template.html — the design tokens and the Simple → Technical pattern already match.

1

What a status report does


A status report answers one question fast: is everything okay right now? The big numbers up top are the vital signs — uptime, speed, errors, traffic — each with a small arrow showing whether it got better or worse since yesterday. Below them, a table lists every part of the system, one row each, with a colored badge saying whether it is fine, struggling, or down.

Think of it like… the dashboard of a car. The speedometer and fuel gauge are your KPI tiles — one glance tells you if something needs attention. The row of warning lights is the status table: each light is a part of the engine, and green means relax, amber means watch it, red means stop.

What the numbers actually mean

Uptime is the share of time the service answered successfully over the window (here, rolling 30 days). p95 latency is the response time that 95% of requests beat — a better health signal than the average because it catches the slow tail real users feel.

Error rate is the fraction of requests returning 5xx / failed responses. Requests/min is throughput — useful context, since a latency spike at 10× traffic reads very differently than one at idle.

Delta colour, not arrow direction

Colour encodes good vs bad, never up vs down. Higher uptime is good (green); higher error rate is bad (rust) even though both arrows point up. The eye should read the colour first and the arrow second.

2

The report, live


This is the format itself: four KPI tiles, then a per-service status table. Hit Refresh to pull a new reading, or turn on Live to watch the numbers and badges tick — the way an on-call engineer sees them.

Service health — Atlas API platform

production · us-east · rolling 30-day window

All systems operational
last updated just now
Uptime · 30d
99.98%
+0.04 pts
p95 latency
214ms
−18 ms
Error rate
0.12%
+0.05 pts
Requests / min
48.6k
+6.2%
Per-service status
Service Status Error rate Last incident

One model, two views

A single array of service objects drives both the table and the rollup pill. Each tick perturbs the metrics within realistic bounds, recomputes each service's status from its error rate, then re-derives the overall banner: any outage → red, any degraded → amber, else green. The KPI deltas are coloured by meaning (good/bad), not by arrow direction.

Accessibility

The “last updated” text is an aria-live="polite" region so screen readers announce refreshes without stealing focus. Status is never colour-only — every pill pairs the hue with a text label and a dot. Live mode is a real aria-pressed toggle; sparkline SVGs carry role="img" + aria-label.