Announce an incident postmortem
Customer-facing postmortem after a service outage or quality incident.
Hi {{firstName}},
On {{date}} between {{startTime}} and {{endTime}} UTC, {{product}} was {{symptom}}. About {{affectedPct}}% of users were affected. I'm sorry.
**What happened:**
{{cause}}
**What we did to fix it:**
{{fix}}
**What we're changing so it doesn't repeat:**
1. {{prevention1}}
2. {{prevention2}}
3. {{prevention3}}
If your work was impacted, hit reply. I'll review each one personally.
— {{founderName}}Why this works
Postmortem emails earn or lose customer trust in a single send. Specific, owned, and forward-looking versions earn trust; vague apologetic versions lose it.
**Subject names the incident.** 'About the {{date}} outage' is honest. Vague subjects ('Service update') trigger anxiety and signal evasion.
**Sorry, said early.** The apology should appear in the first paragraph. Burying it after the technical explanation reads as defensive.
**Cause stated specifically.** 'Database connection pool exhaustion under the new query pattern' beats 'a technical issue.' Technical readers (developers, ops teams) value the specifics; non-technical readers skim past them but notice the specificity.
**Three prevention steps.** Not 'we're investing in reliability' (vague), not one step (insufficient), not ten (overpromising). Three is the credible number for forward-looking commitments.
**Founder personal review offer.** 'I'll review each one personally' commits the founder to actual response. Don't ship this template if you won't follow through.
This pattern can move trust dramatically. The customer who would have churned because of the outage often stays because of the postmortem.