# Postmortem — Template Use for incident write-ups. The structure follows the standard blameless format: what happened, what was supposed to happen, why it didn't, what we change. ## Sections - Summary (two or three sentences: who was affected, for how long, by what) - Impact (the numbers: users, requests, dollars, internal teams) - Timeline (UTC timestamps, one row per significant event) - Root cause (the chain of decisions and conditions that produced the incident; not a single "the bug") - Detection (how we found out, and how long after it started) - Response (what we did, what worked, what didn't) - Recovery (what we did to get back to a steady state) - Lessons (the things we want to remember) - Action items (table with owner, due date, status) - Related (links to the incident ticket, runbook, and follow-up docs) ## Anti-patterns - Don't assign blame. The postmortem is about the system, not the person. - Don't hide the timeline. The reader's first question is "how long"; the timeline is the answer. - Don't list action items without owners. An action item without an owner is a wish. ## Storage template ```xml
| Date | {YYYY-MM-DD} |
|---|---|
| Severity | {SEV-1 / SEV-2 / SEV-3} |
| Duration | {start} → {end} (UTC) |
| Incident commander | {name} |
{two or three sentences}
| Time | Event |
|---|---|
| {HH:MM} | {event} |
{chain of decisions and conditions}
{how we found out, and how long after the incident started}
{what we did}
{how we got back to steady state}
| Action | Owner | Due | Status |
|---|---|---|---|
| {action} | {owner} | {YYYY-MM-DD} | {OPEN / DONE} |