What a status page is
A status page is a public page that says whether your service works right now, and what you are doing about it when it doesn't. It is not your internal dashboard: it is written for customers, in their words, and it only shows what they can act on.
It answers three questions before anyone has to ask them: is it just me, are they on it, and when will it work again. Every question it answers is a support ticket nobody has to write, and a frustrated customer who knows you have noticed.
What belongs on it
- The parts customers recognize. "Website", "API", "Dashboard", "Email delivery", not server names. A handful is enough.
- The current state in plain words. "All systems operational", "Partial outage". Colors help, but the words carry the meaning, for people who don't see the colors too.
- Open incidents, at the top, with the latest update first and a time on every update.
- Planned maintenance, announced ahead of time.
- History: past incidents and daily uptime, so a visitor can see this isn't the third outage this week, or that it is and you are open about it.
- A way to follow along: email updates, a feed, or both, so people don't have to keep reloading.
Host it apart from what it reports on. A status page served by the same servers as your product goes down with it, exactly when it is needed.
The four stages of an incident
Most incidents move through the same stages. Naming them tells readers where you are at a glance.
| Stage | What it means | An update might say |
|---|---|---|
| Investigating | You know something is wrong, not yet why. | Some customers can't sign in. We're looking into it and will post again within 30 minutes. |
| Identified | You know the cause and are fixing it. | A database update slowed sign-ins. We're rolling it back; sign-ins should recover within the hour. |
| Monitoring | A fix is in; you are watching it hold. | Sign-ins work again. We're watching error rates before we close this. |
| Resolved | It is over. | Sign-ins have been normal since 14:20 UTC. Sorry for the trouble; a summary of what happened follows. |
How to write an update
- Post early. The first update can be short: you know, you are on it. Silence reads as not knowing.
- Describe what customers experience. "Payments fail at checkout" beats "elevated 5xx rate on the billing service".
- Say who is affected, if you know: one region, one feature, new sign-ups only.
- Say when the next update comes, and keep that promise, even if the update is "no change yet".
- Use one time zone, and say which. UTC avoids every daylight-saving question.
- Don't guess. No cause until you know it, no time to fix unless you are confident. A promise you break costs more than the one you didn't make.
- Close it properly. Say it is over, since when, and whether anything is left for customers to do, such as retrying a failed payment.
Keep each update to a few sentences. Readers want the state, the impact and the next step, not the debugging story. That belongs in the postmortem.
How often to post
While an incident is open, post whenever something changes, and otherwise at the time you promised. For a long incident, promise the next update within 30 to 60 minutes rather than hours: what matters most is that the promised time is kept. Once a fix is in, one more update when you are sure it holds is enough.
The postmortem
For anything customers noticed, a short write-up afterwards earns more trust than the outage cost:
- Summary: what happened, in two sentences.
- Impact: who was affected, how, and for how long, with times.
- Cause: what went wrong, without blaming a person.
- Fix: what ended it.
- What changes: what you do so it doesn't happen again, or is caught sooner.
Publish it within a few days, while people still remember the outage, next to the incident it explains.
Planned maintenance
Announce maintenance ahead of time, with the window in UTC and what will be unavailable. During the window, the page should say maintenance rather than outage, so nobody mistakes planned work for an incident.
How BBoxProbe handles it
- Every plan comes with a status page at
bbox.to/your-name, served apart from your own servers, in one of 4 layouts: Globe stage, Calm, Split view, and Map. - It shows each monitor's last 90 days, its uptime, each city's latest check, open incidents, maintenance and the incidents of the last 90 days.
- When a monitor goes down or becomes unstable, an incident opens on its own, marked Detected until you post an update, and closes when it is back.
- Updates take the four stages above: Investigating, Identified, Monitoring, and Resolved. Times show in UTC. A resolved incident can carry a postmortem.
- Maintenance windows show on the page a week ahead and as maintenance while they run, and keep alerts quiet.
- Visitors can subscribe by email (they confirm first) and get an email when an incident starts, is updated and ends. There is an Atom feed, a JSON summary and a badge too.
Status pages has the rest.