The worst status update is no update. The second worst is a paragraph that says nothing. You do not need poetry. You need a cadence customers can trust.
The first message (minutes, not hours)
Include:
- What is affected — Login, API, Billing — customer words.
- How bad — down vs degraded, and who feels it if you know.
- That you are on it — without a fake ETA.
- When you will post again — "next update in 30 minutes" is a promise. Keep it.
Example:
We are investigating elevated errors on API. Some customers cannot load workspaces. Next update by 14:30 UTC.
That is enough for message one.
Updates after that
When something changes — mitigation shipped, impact narrowed, resolved — post. If nothing changed but the clock hit your promised time, post anyway: "Still investigating; next update in 30 minutes." Silence after a promised time feels like abandonment.
Phrases to retire
- "We are currently experiencing issues with some services." (Which? How bad?)
- "An underlying third-party provider" with no name when you know and it is public.
- "Should be resolved shortly" when you have no signal.
- "We apologize for any inconvenience" as the entire message.
- Blame theater that argues with customers in public.
Apologize once clearly when you resolve. Spend the incident on facts.
After resolve
- Time it ended.
- Brief impact summary.
- Whether a deeper follow-up is coming.
- Link to postmortem later if you write one — do not stall the resolve note for the essay.
Process beats talent
Put three templates in the runbook: investigating, update, resolved. On-call pastes and fills blanks. The status page is part of the incident, not a marketing task for Monday.
If the page is automated from monitors, still write the human sentence. Green and red are weather. Words are what people remember.