Status pages
Telling people outside the company what is happening, without them having to ask.
A status page is the public face of an incident: what is affected, what is known, and when the next update is coming.
Setup
Settings → Status Page. Choose which components appear and what each is called in public.
| Field | Notes |
|---|---|
| Components | Grouped by what a customer recognises, not by your services |
| Slug | The public URL |
| Subscribers | Email updates when something changes |
Name components the way customers talk. "Checkout" and "Mobile app", not
orders-api and bff-v2. The page exists to answer their question, not to
describe your architecture.
Components map to services
Each public component maps to one or more services, so status is derived from monitoring rather than remembered by a person during an incident.
Automatic status is the default; it can be overridden by hand when the truth is more nuanced than the checks can see.
Publishing an update
From the incident. An update carries a state and a message:
| State | Means |
|---|---|
| Investigating | We know, we do not know why yet |
| Identified | We know why |
| Monitoring | We think it is fixed and are watching |
| Resolved | It is fixed |
Say when the next update will be, and then post one even if nothing has changed. "Still investigating, next update in 30 minutes" costs nothing and stops everybody contacting support to ask.
Subscribers
People can subscribe to email updates. Every publish notifies them.
Writing one
- What is affected, in their words
- What it means for them — "you cannot check out" beats "elevated error rates"
- What we are doing
- When the next update is
Avoid speculation about cause. It is frequently wrong, and the correction is remembered longer than the original.
Public post-mortems
A post-mortem can be published to the same site. Publish it for anything customers noticed — the cost is low and the alternative is that the only public record of the incident is the outage itself.
Where this behaviour lives: backend/internal/handler/status_handler.go, frontend/src/app/status/. If the code and this page disagree, the code is right — please fix the page.
Part of Incidents and on-call — Turning a reading into a page, and a page into a resolved incident.