What belongs on a status page?
The overall state, a short list of components, ongoing incidents, announced maintenance and the history of the past weeks. Nothing else. A status page is not an architecture diagram; it answers exactly one question: is it you or is it me?
The most important decision is what the components are called, and it comes before any styling. Components are named after what a customer is trying to do, not after what sits in your data centre. “Sign-in”, “Payments”, “File upload” answer the question. “api-gateway-eu-west” and “redis-primary” do not — they are accurate and still useless, because nobody outside your team knows which one is their problem.
Components can be grouped. A group “Web” with the children “Website”, “Console” and “Documentation” shows the summarised state at the top and the detail underneath for whoever wants it. That keeps the page short without dropping information.
Every component carries a state, and that state is computed rather than typed in: operational, degraded, partial outage, major outage, under maintenance. It follows the monitoring of the service behind it — so the page cannot say “all good” while the checks have been failing for an hour.
- Operational
- All checks pass. The normal state, shown ninety-nine percent of the time.
- Degraded
- The service answers, but not correctly — too slowly, or with a response that violates an assertion.
- Partial outage
- Some measurement locations or some components of a group are affected, not all of them.
- Major outage
- The service is unusable. The state visitors actually come to the page for.
- Under maintenance
- An announced window is running. Visible from the announcement until it closes, so nobody mistakes a planned restart for an outage.

To maintain a state by hand, create the service with the check type “Manual”. No automatic check runs, and the state only changes when a human changes it — useful for anything that cannot be measured from the outside, such as a delivery service or a phone system.

