How to Write an Outage Apology Email with a Timeline
Incident emails go wrong when the model invents a root cause, a percentage of customers, a credit amount, and a promise that this will never happen again. Legal did not approve those lines. On-call did not want their name in the body. The status page then disagrees with the email because the timestamps were guessed.
The matching generator is the Service Outage Apology Email with Status Timeline prompt. Browse related cards in the PromptDig library (Browse more prompts). When a filled run survives, share the version you actually use (Share a prompt).
Fact table in UTC, blanks stay UNKNOWN
Start, detect, mitigate, resolve. If you do not have a probe before the first public report, the start is approximate and everything before it is UNKNOWN. Do not fill from vibes.
Times stay in UTC. Label local only if Inputs gave it. Next update time appears only if you provided one. "We will update you shortly" with no clock is how you inherit a second apology.
Severity on the status page is an external one-liner. No internal severity names unless review allows them. "SEV2" is not a customer sentence.
Email structure, then a timeline of actions not theories
Two subject options. A from-name suggestion. Body: apology, what they saw, timeline, what you know, what you do not know, what they can do now. If Tone is plain, do not stack "we know this is frustrating" more than once.
Scope is the slice you can honestly name: a parser pool, a region, a feature. If you cannot honestly say a percent, do not. Existing tickets staying readable while inbound mail fails is a useful distinction. Inventing "most customers" is not.
Status-page bullets are timestamped actions or observations. Failover, rollback, queue depth, backlog drain from a UI you named. A guessed memory leak is not a bullet. If RCA is not ready, write "RCA not ready" and refuse to name a vendor or an engineer as the villain.
Do not name on-call staff in the customer email. Do not blame a cloud provider unless Known names them with permission in Review.
Credits, internal phrases, and a follow-up stub
Credits paragraph only if Credits has language you are allowed to mention. Else: no credit language in this send; do not promise a token. CS can follow contracts later. The generator should not mint a 10 percent coupon to sound kind.
Keep internal: hostnames, Slack channels, employee names, dashboard screenshots used as a flex, internal error-rate numbers the author forbade quoting.
Follow-up email for when RCA exists: headings only. What happened, customer-visible window, trigger, detection gap, mitigations that worked, what you still do not know, what changes in deploy, how you will tell them. No fake findings filled in.
Support path is the one you typed. If inbound delayed mail should appear without resending, say so. If they should reply with a Message-ID after a named time, say so. Do not invent a status phone number.
Fill the card, then run
Paste times you can defend and the symptom customers actually saw. Unknowns stay labeled unknown.
Product and what broke: [Product]
Customer-visible symptom: [Symptom]
UTC start, detect, mitigate, resolve: [Times or UNKNOWN]
Who is affected, as we can slice it: [Scope]
What we know vs guess: [Known]
What we tried: [Actions]
Current status: [Status]
Credits we may mention: [Credits or none]
Support path: [Support]
Legal / brand review notes: [Review]
Tone: [Tone]
Audience: [Audience]
A short apology with a UTC timeline beats a warm essay with a guessed RCA. When a run keeps the leak theory internal and omits credits you did not authorize, share that filled card. The next incident will arrive faster than a style guide.