customer-facing-postmortem

# Writing a customer postmortem Customers forgive outages. They do not forgive discovering it was worse than they were told. ## The structure What happened, in their terms · when it started and ended, in UTC with a local note · who and what was affected, specifically · what caused it, honestly and without internal detail · what was done · what changes so it does not recur, with dates. ## Honesty rules Say "we deployed a change that…" rather than "an issue occurred". Passive voice reads as evasion. Never name an individual — the failure is the system's, and a named engineer is a hostile act. ## Data If data was lost, exposed or delayed, say so in the first paragraph. Burying it turns an outage into an incident of trust, and it always surfaces. ## The commitments Only what is already scheduled with an owner. A postmortem promise that does not land is worse than not making it. ## Never Overstate the fix, promise it cannot happen again, or publish before the timeline is confirmed.