Write the communications for an incident that is still in progress. I need text I can post now and a rhythm for the updates that follow.
What is affected: {{e.g. checkout fails for roughly 40% of EU customers; the /orders endpoint returns 502}}
When we first saw it (not when it began): {{timestamp and timezone}}
What we know and do not know right now: {{e.g. correlated with a config deploy at 14:07; root cause not confirmed; rollback in progress}}
Current state: {{investigating | identified | monitoring}}
Severity as declared: {{e.g. SEV1, full outage | SEV2, degraded}}
Workaround, if any: {{e.g. retry after 60 seconds; use the previous API version; none}}
Where customers should look for updates: {{status page URL}}
Audiences that need their own line: {{e.g. enterprise account managers; the exec on-call; the support team answering tickets}}
Words we are careful with: {{e.g. do not say "data loss" until confirmed; we cannot promise a resolution time}}
Produce:
**Status page post for the current state.** Under 80 words. What a customer sees, what we are doing, the workaround if one exists, and a "next update by" time. No root-cause speculation, no apology yet, no internal system names. Write it so it is still accurate if nothing changes in the next 30 minutes.
**The next three posts, pre-written.** One for each state that follows the current one (identified, monitoring, resolved), with brackets for the details we will fill in. The resolved post states the impact window and whether a post-incident review will be published.
**One line for leadership.** Business impact in the numbers we have (customers, orders, revenue rate, region), what is being done, and when the next decision point is. No system names; leadership cannot act on those.
**Support script.** Two sentences an agent can say to a customer, and the one thing they must not say.
**Per-audience lines** for the other audiences I listed, each with the channel and whether it goes out now or after the status page updates.
**Cadence.** A concrete update interval for this severity, and the rule for when an update time arrives with nothing new to say (that is still an update, with the next time). Point every channel back to the status page so no two channels carry different facts.
Flag anything in my "what we know" that reads as a guess presented as a fact, and rewrite it as what we have observed.Tip: Post the status page text first and every other channel after it, so the status page stays the source the others quote. A resolved post that omits the impact window is the most common reason customers write in afterwards.
incident-responsestatus-pagecommunicationson-call