incident-postmortem

Topics in the source

• Incident Post-Mortem
• Blameless Principle
• When to Use
• Input Requirements
• Incident Metadata
• Impact
• Timeline Events
• Contributing Factors

Guide a team through writing a structured, blameless post-mortem after a production incident. The output is a document that builds shared understanding, identifies root causes without blame, and produces concrete action items to prevent recurrence. Systems fail, not people. The goal is to understand HOW the incident happened — not WHO caused it. Avoid language like "X forgot to", "Y should have known". Use "the system did not", "the process lacked", "the alert did not fire". Production outage or service degradation has been resolved A significant near-miss occurred (would have been an incident if caught later) User-facing errors, data loss, or SLA breach happened Team wants to capture learnings before context fades Not for: Minor bugs caught in staging, planned maintenance windows, or incidents with no learning value. Gather these details before writing the post-mortem. Ask for anything missing: Incident title (short, descriptive) Date and time of detection (with timezone) Date and time of resolution Severity / impact level (P1–P4 or equivalent) Incident commander / on-call owner Affected services and systems User-facing impact (errors, slowness, full outage) Estimated number of us

This is an excerpt. Refer to the complete source and its current requirements.