What a status page should say during an incident
Customers do not need every detail during an outage. They need clear, regular and honest updates. Here is what to write.
During an outage, your status page is the most visited page you have. Customers check it before they open a ticket, and what they read there shapes how they feel about the incident long after it ends. Here is what a good status page update says, and what it leaves out.
1. Post the first update fast
The first update matters more than the perfect update. Post within minutes of confirming the problem, even if all you can say is that you are investigating. Silence makes customers assume the worst and fills your support queue.
2. Say what is affected
Name the feature, not the server. “Checkout is failing for some customers” is useful. “Elevated error rates on api-3” is not. Mark the affected components on your status page so customers can see at a glance whether they are affected.
3. Use plain language
Write for the customer, not for your team. Skip internal names, acronyms and guesses about root cause. Short sentences in plain words are easier to read on a phone during a stressful moment.
4. Give a time for the next update
If you do not know when the fix will land, say when you will post again. “Next update in 30 minutes” sets an expectation you can always meet. Then meet it, even if the update is that work is still in progress.
5. Notify subscribers
Not everyone will check your status page. Subscribers in Navy get every update by email, so customers hear from you first instead of finding out from their own users. Keep each update short enough to read in the notification.
6. Close the incident clearly
When the service recovers, say so plainly and say when it recovered. Keep the incident in a monitoring state for a while if you are not yet sure the fix holds. The 90-day uptime bars will show the incident to anyone who looks later.
7. Follow up with a postmortem
For larger incidents, link a postmortem once it is ready. Explain what happened, what you changed and what you are doing to prevent it. Customers rarely leave over an outage. They leave over an outage that was handled badly.
| Incident stage | Example update | Update interval |
|---|---|---|
| Investigating | We are looking into failed logins | 15 to 30 min |
| Identified | The cause is a database failover | 30 min |
| Resolved | Logins have worked normally since 14:20 UTC | Final |
A status page earns trust during the worst hour of the month. Post early, write plainly, update on schedule and close the loop when it is over.
