System Status
Last updated:
Practical patterns for communicating platform health, incidents, and recovery with calm clarity.
01 — Foundation
Status communication reduces uncertainty
Good status systems preserve trust. Bad ones create rumours.
System status helps users understand platform health — current service state, active incidents, affected functionality, and expected recovery. Calm, transparent updates beat vague “we are investigating” pages that never change.
02 — Content
What to communicate
Users need severity, scope, and timeline — not engineering acronyms alone.
- clear severity — operational, degraded, partial outage, major incident
- name affected services — “Checkout”, “File uploads”, not only “API”
- visible update history with timestamps — show progress, not silence
- calm plain language — avoid jargon overload and blame-shifting
03 — In-app
Banners, pages, and subscriptions
Match the channel to how serious the incident is.
- minor issues — Announcement Banners with link to status page
- major outages — dedicated status page or Maintenance States treatment
- RSS, email, or webhook subscriptions for teams who need proactive notice
- acknowledge incidents quickly — delayed silence amplifies anxiety
<section role="region" aria-label="Service status">
<p><strong>Degraded:</strong> Report exports are slow. <a href="/status/">Updates</a></p>
</section>04 — Accessibility
Readable and accessible status
Status must work on mobile, at zoom, and with assistive technology.
- sufficient contrast; do not rely on colour alone for severity
- responsive layout — status pages are often read on phones during incidents
- meaningful headings and landmarks — not an unlabeled wall of updates
05 — Review
Before you approve
A short checklist for system status in code review.
- current health, active incidents, and recovery expectations are clear
- updates are timely and understandable
- in-app surfacing matches severity; status page is linkable