Writing a good public status update is harder than it looks. The goal is to convey maximum clarity with minimum words, in a tone that is honest without being alarming. Think of it as writing a short, factual news bulletin — not a technical report, and not a marketing apology.
The Four Pillars of a Status Update
Every public update, from the first "Investigating" post to the final "Resolved" message, should answer these four questions:
-
What is the current state? Use a consistent set of status labels so customers understand where you are in the resolution process. Standard stages are: Investigating (we know something is wrong, we don't know why yet), Identified (we know the cause and are working on a fix), Monitoring (a fix has been applied and we are watching to confirm it holds), and Resolved (service is fully restored).
-
Who is impacted, and how? Be specific about the user experience. Don't say "The auth service is experiencing elevated error rates." Say "Users may be unable to log in or may be logged out unexpectedly." Translate technical symptoms into user-facing consequences.
-
What are we doing? Briefly state that you are actively working on it. "Our engineering team has identified the cause and is working to restore service." This is not just reassurance — it signals that the incident is staffed and being actively managed.
-
When is the next update? Set a concrete expectation. "We will provide another update by 14:30 UTC." You must meet this deadline, even if the update is just "We are still investigating and have no new information to share. Next update in 30 minutes." Missing a promised update is worse than having nothing new to say — it signals that you've lost control.
The Update Progression: A Real Example
Here is how a single incident's public updates might evolve over time:
| Time | Status | Message |
|---|---|---|
| 13:00 | Investigating | We are investigating reports of users being unable to complete checkout. We will provide an update by 13:30. |
| 13:30 | Investigating | We are still investigating the checkout issue. Our team is actively working to identify the root cause. Next update by 14:00. |
| 13:55 | Identified | We have identified the cause of the checkout issue and are implementing a fix. We expect service to be restored within 30 minutes. Next update by 14:30. |
| 14:20 | Monitoring | A fix has been deployed. We are monitoring the system to confirm full recovery. Checkout should now be working for most users. |
| 14:35 | Resolved | The checkout issue has been fully resolved. All services are operating normally. We apologize for the disruption and will publish a post-mortem within 72 hours. |
Notice how each update is short, factual, and follows the same structure. Customers can scan it in five seconds.
Things to Avoid
- Technical Jargon: Don't mention Kubernetes pods, database shards, load balancers, or specific error codes. Customers don't care about your infrastructure — they care about their workflow.
- Blame: Never blame a vendor, a specific team, or an individual in a public update. Take responsibility as a company. "We are experiencing an issue with a third-party provider" is acceptable; "Our CDN vendor broke everything" is not.
- Premature ETR: Avoid giving an Estimated Time to Recovery unless you are highly confident. Missing a promised ETR destroys trust faster than not giving one at all. If you do give one, add a buffer — it's better to resolve early than late.
- Passive Voice Evasion: "Errors were encountered" is weaker and less trustworthy than "Users are experiencing errors." Own the problem directly.
A common interview scenario: "You've just deployed a fix and the metrics look stable. Do you immediately post 'Resolved' on the status page?" The correct answer is no — you post Monitoring first. You watch the metrics for a defined period (typically 15–30 minutes) to confirm the fix is holding before declaring resolution. Declaring "Resolved" and then having the incident recur is one of the most damaging things you can do to customer trust.