Who it is for
Your status page is not for your team. It is for someone who is not technical, is already annoyed, and wants one question answered fast: is this broken for everyone, or is it just me?
That framing settles most design arguments. The current state should be readable in under two seconds without scrolling, in plain language, above everything else.
Host it somewhere else
A status page that runs on the infrastructure it reports on is useless at precisely the moment it matters. If your data centre is having a bad day, your status page must not be having the same bad day.
Use a separate provider, a separate region, and a separate DNS zone if you can. This is not paranoia — the correlated failure is the normal case.
Hosting status.yourcompany.com is fine, but if it resolves through the same DNS zone that just broke, nobody can reach it. Confirm your status page stays reachable under the failure modes you are most likely to have.
Update cadence
The first update should go out within minutes of confirming impact, with whatever you know. After that, commit to a rhythm and hold it — every thirty minutes during an active incident is a reasonable default.
Crucially, promise the next update time rather than a resolution time. "Next update at 14:30" is a promise you can always keep. "Fixed within the hour" is one you often cannot.
The four states
- InvestigatingYou know something is wrong and are looking. Post this fast — speed matters more than detail here.
- IdentifiedYou know the cause. Say what is affected and what still works.
- MonitoringA fix is deployed and you are watching. Do not skip this straight to resolved.
- ResolvedConfirmed healthy, with a brief summary and, for serious incidents, a postmortem commitment.
Tone
Write plainly. "Users cannot log in" beats "authentication service degradation". Corporate hedging reads as evasion to someone who is already frustrated, and it makes the outage feel worse than it is.
Do not apologise in every sentence, and do not be flippant. Acknowledge the impact once, clearly, and then focus on facts.
What to disclose
You do not owe the public your internal architecture, and you should not publish anything that helps an attacker. But vagueness that leaves users unable to work out whether they are affected defeats the entire purpose of the page.
- Always say which user-facing capability is impaired
- Say what is still working — this is more reassuring than most teams realise
- Give a rough scope: all users, some users, one region
- Skip internal system names that mean nothing to your customers