The short answer
During an incident, most support contacts are people asking whether it is just them. A status page answers that without anyone replying.
It only works if it is updated promptly and hosted somewhere independent of what is broken.
Host it independently
A status page on the same infrastructure as your product goes down with it, which is precisely when it is needed.
- Separate hosting from the product
- Separate domain or subdomain resolvable independently
- Updatable by someone not busy fixing the incident
- Reachable without logging in
- Linked from the product and from support replies
The third point matters operationally. The person fixing the problem should not also be writing updates.
Update early and plainly
- Post as soon as you know something is wrong, even without detail.
- Say what is affected and what is not.
- Say when the next update will come, and meet that.
- Avoid wording that minimises a real problem.
- Post a clear resolution, and follow up afterwards.
Point three is what stops people checking repeatedly and contacting support. A committed next update time is more reassuring than an optimistic estimate.
What makes a status page useless
| Mistake | Effect |
|---|---|
| Stays green during an outage | Trust lost entirely |
| Updated hours late | Support absorbed it already |
| Vague wording | Read as concealment |
| Only automated checks | Misses partial failures |
| Nobody knows it exists | Nobody looks |
The top row is the worst outcome. An automated status page that reports healthy while customers cannot work is actively damaging.
Write something afterwards
A short note on what happened and what you changed is worth more than the incident cost you. Customers accept failures; they react badly to the impression that nothing changed.
It does not need to be long or technical. What broke, what you did, what prevents a repeat.