Incident and outage notice

Use when something broke, customers noticed, and the email has to hold up when it gets screenshotted.

incident-apology-email.md

Download .md

You are a customer communications writer handling a live incident. You are not managing this with tone.

What happened, in technical terms: {{INCIDENT_FACTS}}
Who was affected, how, and over what window: {{IMPACT_AND_WINDOW}}
Current status and what is confirmed fixed: {{CURRENT_STATUS}}
What customers must do, if anything: {{CUSTOMER_ACTION}}
Who signs the message and where questions go: {{SENDER_AND_CONTACT}}

Output three numbered sections.
1. The email: subject, preheader, and a body of 120 to 200 words ordered as what happened, who it affected using {{IMPACT_AND_WINDOW}}, what we have done, {{CUSTOMER_ACTION}}, and the contact from {{SENDER_AND_CONTACT}}.
2. A table: Statement in the email | Source in {{INCIDENT_FACTS}} or {{CURRENT_STATUS}} | Confirmed, or still under investigation.
3. "Not saying yet": the questions customers will ask that the supplied facts cannot answer, each with a holding sentence.

Rules:
- No sentence enters section 1 unless it traces to a supplied fact. Anything unverified belongs in section 3.
- Do not promise it will never recur, do not name a vendor as the cause, and do not write "may have been affected" where {{IMPACT_AND_WINDOW}} states who was.
- Apologise once, early, with no qualifier attached.
- End with a line telling me to have legal or security review this if the incident touched customer data.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{INCIDENT_FACTS}}
{{IMPACT_AND_WINDOW}}
{{CURRENT_STATUS}}
{{CUSTOMER_ACTION}}
{{SENDER_AND_CONTACT}}

Getting a better result

Send before the cause is fully understood. A short accurate notice beats a complete one that arrives after the complaints.
Give the affected window in the reader time zone. Vagueness about scope reads as evasion.
Keep the "not saying yet" list. It is the agenda for the follow-up message and for the post-incident write-up.

Questions about this prompt

When does this beat a status page update?

When customers were affected and will not think to look at the status page, or when the incident touched their data or their money. A status page serves people already checking. This is written to hold up when it gets screenshotted, which is a different bar from a running incident log.

What facts do I need before writing it?

The confirmed technical detail, who was affected and over what window, current status, what customers must do, and who signs it with a contact route. You do not need the full cause. The prompt separates confirmed from unconfirmed, so you can send before the investigation closes.

What do the three sections cover?

A 120 to 200 word notice, a table tracing every statement to a supplied fact and marking it confirmed or still under investigation, and a "not saying yet" list with holding sentences. Keep that last list. It is the agenda for the follow-up message and for the post-incident write-up.

Which line ages worst?

Saying customers may have been affected when your impact window states exactly who was. It reads as hedging to the people hit and worries everyone else. Naming a vendor as the cause and promising it will never recur are close behind. Have legal review anything touching customer data.