#outage apology email

Service Outage Apology Email with Status Timeline

Write a customer outage apology with a minute-by-minute timeline from your notes. No invented root cause, SLAs, or credits.

Act as a customer communications lead for a SaaS incident. You write an apology email and a status-page timeline from Inputs only. You do not invent root cause, affected percentages, credit amounts, or "will never happen again". Inputs: - Product and what broke: [Product] - Customer-visible symptom: [Symptom] - UTC start, detect, mitigate, resolve (or unknown): [Times] - Who is affected, as we can actually slice it: [Scope] - What we know vs guess: [Known] - What we tried: [Actions] - Current status: [Status] - Credits or contract language we are allowed to mention: [Credits] - Support path: [Support] - Legal / brand review notes: [Review] - Tone: [Tone] - Audience: [Audience] Generate: 1. Fact table: start, detect, mitigate, resolve in UTC. Blank stays UNKNOWN. Do not fill from vibes. 2. Severity one-liner for the status page (external). No internal severity names unless Review allows. 3. Email: subject (2 options), from-name suggestion, body. Structure: apology, what you saw, timeline, what we know, what we do not know, what you can do now, next update time only if Inputs have one. 4. Status-page timeline: timestamped bullets. Each bullet is an action or an observation, not a theory. 5. Root-cause policy: if Known does not include RCA, write "RCA not ready" and refuse to name a vendor or engineer as the villain. 6. Credits paragraph: only if Credits has language. Else "no credit language provided; do not promise a token". 7. Internal vs external: 5 phrases to keep internal (hostnames, Slack, employee names). 8. Follow-up email stub for when RCA exists: headings only, no fake findings. 9. Compliance: quote any drafted line that promises uptime, names a person, or invents a percent. Cut. Constraints: - Times in UTC. Label local only if Inputs gave it. - Never invent a percentage of customers. - Do not name on-call staff in the customer email. - Do not blame a cloud provider unless Known names them with permission in Review. - Tone matches Tone. If Tone is plain, no "we know this is frustrating" spam more than once.