📣 Incident Communication Templates: Status Page, Stakeholder, and Exec

Writing incident comms from scratch while an incident is on fire is a bad idea, and yet it’s what most teams do. Someone freezes in front of an empty status-page box trying to find the right words for “we broke checkout” without admitting fault, panicking customers, or over-promising a fix time — and meanwhile the incident keeps burning. Under stress, prose is expensive. The fix is to have the words mostly written before you need them.

These are the incident communication templates I keep on hand, organized by audience, because each audience needs a genuinely different message. A status-page update, an internal stakeholder note, and an executive summary describing the same incident should read differently — different detail, different register, different purpose. Copy these into your runbook, adapt the bracketed bits, and you’ll never again lose five minutes to the blank page.

The one rule behind all of them: register by audience

Before the templates, the principle that makes them work. Each audience cares about a different thing:

• Customers care whether it’s affecting them and when it’ll be fixed. They want plain language, no jargon, no blame, and no root-cause speculation.
• Internal stakeholders care about impact and what’s being done, in enough detail to answer their own stakeholders. They can handle more specifics.
• Executives care about business impact, customer/reputational risk, and whether they need to do anything. They want the bottom line first, brief.

Send the wrong register to the wrong audience and it backfires — technical detail panics customers, vague reassurance frustrates engineers, and a wall of engineering detail wastes an exec’s thirty seconds. Match the message to what the reader actually needs.

Status page / customer-facing templates

Plain, calm, no jargon, no root cause, no fault. Never promise a fix time you don’t know — promise the next update instead.

Investigating:

[Investigating] We're aware of an issue affecting [feature, in
plain terms, e.g. "completing purchases"]. Some customers may
experience [symptom]. We're investigating and will post an
update by [time].

Identified / mitigating:

[Identified] We've identified the cause of the issue affecting
[feature] and are working on a fix. [If true: "You may continue
to experience [symptom] until this is resolved."] Next update by
[time].

Monitoring:

[Monitoring] We've applied a fix and [feature] is recovering.
We're monitoring to confirm the issue is fully resolved. Next
update by [time].

Resolved:

[Resolved] The issue affecting [feature] has been resolved as of
[time]. Everything should now be working normally. We're sorry
for the disruption. [If warranted: "We'll follow up with more
detail once we've completed our review."]

Notes that keep these safe: never speculate on cause publicly (“it might be the database” ages badly and invites follow-ups you can’t answer). Never blame a vendor by name mid-incident. And keep the “sorry” simple and human — over-apologizing reads as panic, none reads as cold.

Internal stakeholder templates

More detail, still structured, sent to the internal channel or notification list on a cadence. These let stakeholders self-serve instead of pinging responders.

Initial:

🔴 INCIDENT — [short name] — SEV[x]
Impact: [what's broken, who's affected, since when]
Customer-facing: [yes/no — is the status page updated?]
Current focus: [what the team is doing right now]
IC: [name] | Comms: [name]
Next update: [time]

Ongoing update:

🟠 UPDATE — [short name] — SEV[x] — [time]
Change since last update: [what's new]
Current status: [mitigating / monitoring / etc.]
Customer impact now: [better/same/worse]
Next update: [time]

Resolution:

🟢 RESOLVED — [short name] — [time]
Duration: [start]–[end] ([x] min)
What happened: [one-line, factual, no blame]
Customer impact: [summary]
Follow-up: postmortem owned by [name], due [date]

The cadence line at the bottom of each is the load-bearing part. A predictable “next update at X” stops stakeholders from interrupting the responders, even when the update is just “still working, no change.”

Executive templates

Bottom line first, brief, framed around business and customer risk. An exec should be able to read it in fifteen seconds and know whether they need to act.

Initial exec notification (SEV1):

Heads up: we have a SEV1 incident. [Feature] is down for
[roughly who/how many] customers as of [time]. Team is engaged,
[name] is running it. Customer comms are [posted / going out].
Biggest risk right now: [e.g. "revenue impact from failed
checkouts; reputational if prolonged"]. I'll update you in 30
min or sooner if it materially changes. No action needed from
you right now [or: "we may need [X] — will confirm"].

Exec resolution:

Resolved: the SEV1 affecting [feature] is fixed as of [time],
total customer impact ~[duration]. [One-line what happened.]
No further customer impact expected. We'll run a blameless
postmortem and share findings by [date].

The “no action needed from you” line matters more than it looks. Execs often jump into incidents wanting to help and end up adding coordination overhead. Telling them plainly whether you need anything keeps them informed without pulling them into the war room.

Common comms mistakes

• Speculating on cause publicly. “Likely a database issue” becomes a promise and a liability. Say what customers experience and what you’re doing, not why you think it broke.
• Promising a fix time. You rarely know it, and a missed ETA erodes trust twice. Promise the next update, not the fix.
• Going silent. No update for an hour reads as “they’ve lost control.” Post on cadence even when there’s nothing new.
• One message for all audiences. Blasting the engineering detail to customers or the customer platitude to engineers. Match register to reader.
• Comms as an afterthought. If the IC is also writing every message, comms will lag. Assign a comms owner on anything past a small incident.

Where AI helps — draft fast, human sends

Comms is one of the best AI assists in incident response, because it’s high-volume writing under time pressure with a human easily able to verify the output. Hand the model the facts and the audience and let it draft:

“Write a status-page update for a degraded-checkout incident: customer-facing, plain language, no jargon, no root-cause speculation, ~3 sentences, and promise the next update in 15 minutes. Then a one-line internal update with current severity and what we’re checking.”

The rule is absolute: AI drafts, a human reads and sends. The model doesn’t know what you’ve confirmed versus what you suspect, and a customer-facing message is exactly the wrong place for a confident hallucination. Used with that discipline, it turns three separate messages for three audiences into a ten-second review instead of a five-minute writing exercise. The Incident Response tool produces exactly these audience-tuned comms drafts from a structured assessment.

Wrapping up

The words for an incident should be mostly written before the incident starts. Keep templates for each audience — plain and blameless for customers, detailed and cadenced for stakeholders, bottom-line-first for execs — and adapt the brackets in the moment instead of composing from a blank page. Match register to reader, promise the next update rather than a fix time, and never go silent. Do that and comms becomes the calm, predictable drumbeat that keeps everyone out of the responders’ way.

AI-drafted comms are drafts. A human reads every word and owns every message before it goes out.

Related

• The Communications Lead Role in Incident Response
• Building a Stakeholder Notification Matrix for Incidents
• The Incident Commander Role Explained for Engineering Teams