# 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

{Incident title — short, dated}

Date {YYYY-MM-DD}
Severity {SEV-1 / SEV-2 / SEV-3}
Duration {start} → {end} (UTC)
Incident commander {name}

Summary

{two or three sentences}

Impact

Timeline (UTC)

Time Event
{HH:MM} {event}

Root cause

{chain of decisions and conditions}

Detection

{how we found out, and how long after the incident started}

Response

{what we did}

Recovery

{how we got back to steady state}

Lessons

Action items

Action Owner Due Status
{action} {owner} {YYYY-MM-DD} {OPEN / DONE}
``` ## Cross-references - Storage macros: `confluence-page/references/macros.md` - BASS / AVP page hierarchy — see the owning team's incident process doc