Running a public status page honestly: components, automation and history

What it is

A public status page lists the components of a service with their current state, announces scheduled maintenance and keeps a history of incidents with their updates. It is not internal monitoring: it reports what users experience, in their words, and it is read most on the days the service is down.

Why it matters

Users and support staff check the page before opening tickets; partner teams and automated clients read it or its feed to decide whether to retry or to page their own people. A page that says "all systems operational" during an outage costs more trust than having no page.

How to apply

• Host the page, its DNS and its domain with providers that share nothing with the service: different hosting, different CDN, ideally a different registrar. A page that goes down with the service is decoration.
• Choose components by what users can tell apart: web app, API, email delivery, payments; not internal cluster names. Keep the list short enough that every component has a distinct user-visible failure mode.
• Define the states (operational, degraded, partial outage, major outage, maintenance) in user terms and write the definitions down so two people post consistently.
• Grant posting rights to everyone on call and remove approval steps. The first update may say only "investigating reports of errors in X" and when the next update comes.
• Post on a fixed cadence during an incident even without news; silence reads as abandonment.
• Automate the obvious half: an external probe that fails for several minutes may flip a component to degraded automatically, with a person confirming or correcting. Do not automate "resolved"; a person confirms recovery from the user's side.
• Announce maintenance windows in advance with start, expected end and expected effect in a named time zone, and close them when the work is done.
• Keep incident history public with a link to the postmortem summary; it shows how the service handles failure.

Pitfalls

Component states that reflect one region while users elsewhere are down. A "degraded" state used so often it means nothing. Editing or deleting history after the fact. Uptime percentages computed by the page provider from probes that do not match user experience. A page whose only reader is the team that writes it, because nobody linked it from the product and the error pages.