Writing Postmortems

# Postmortem: [Incident Title]

## Metadata
- **Date:** YYYY-MM-DD
- **Incident ID:** INC-YYYY-NNN
- **Severity:** SEV[X]
- **Duration:** [total time]
- **Author:** [name]
- **Reviewers:** [names]
- **Status:** Draft / Under Review / Final

## Executive Summary
[2-3 sentences: what happened, impact, resolution, key takeaway]

## Impact
- **Users affected:** [number or percentage]
- **Duration:** [time]
- **Revenue impact:** [amount or "unknown"]
- **SLO impact:** [error budget consumed]

## Timeline
[Reconstructed timeline from multiple sources]

## Root Cause
[Clear, non-technical description of the root cause]

## What Went Well
[Things that helped during the incident]

## What Went Poorly
[Things that hindered the response]

## Where We Got Lucky
[Things that could have been worse]

## Action Items
| ID | Title | Owner | Due | Priority | Status |
|----|-------|-------|-----|----------|--------|
| AI-001 | [title] | [owner] | [date] | [priority] | [status] |

## Lessons Learned
[Key takeaways for the team]

## Supporting Data
[Links to dashboards, logs, charts]

impact_summary_examples:
  good:
    users_affected: "Approximately 45,000 users (12% of active users)"
    duration: "32 minutes (14:30 - 15:02 UTC)"
    revenue_impact: "Estimated $2,300 in lost transactions"
    slo_impact: "Consumed 15% of monthly error budget"

  bad:
    users_affected: "Some users"
    duration: "About half an hour"
    revenue_impact: "Unknown"
    slo_impact: "N/A"

  why_good_is_better:
    - "Specific numbers are more credible than vague terms"
    - "Stakeholders can assess business impact"
    - "Helps prioritize future prevention efforts"
    - "Creates accountability for measurement"

detection_analysis:
  detection_method:
    - "Automated alert"
    - "Customer report"
    - "Dashboard observation"
    - "Internal team report"
    - "External monitoring"

  time_to_detect:
    description: "How long from incident start to detection"
    target: "< 5 minutes for SEV1"
    actual: "[time]"

  detection_quality:
    - "Did the alert fire correctly?"
    - "Was the severity appropriate?"
    - "Was the runbook linked?"
    - "Did the right person get paged?"

  improvement_areas:
    - "Alert did not fire (monitoring gap)"
    - "Alert fired but wrong team (routing issue)"
    - "Alert fired but not actionable (noise)"
    - "Customer detected before monitoring (detection gap)"

response_analysis:
  time_metrics:
    time_to_detect: "[minutes]"
    time_to_triage: "[minutes]"
    time_to_mitigate: "[minutes]"
    time_to_resolve: "[minutes]"
    total_duration: "[minutes]"

  what_worked_well:
    - "Rapid incident declaration"
    - "Effective communication"
    - "Runbook was accurate"
    - "Rollback was fast"

  what_went_poorly:
    - "Slow initial triage"
    - "Communication gaps"
    - "Runbook was outdated"
    - "Rollback failed first time"

  where_we_got_lucky:
    - "Rollback succeeded on second attempt"
    - "No data corruption occurred"
    - "Traffic was low at time of incident"

  improvement_areas:
    - "Improve triage process"
    - "Update runbooks"
    - "Test rollback procedures"
    - "Add more monitoring"

root_cause_examples:
  bad:
    technical: "Connection pool exhaustion due to leaked database connections"
    problem: "Too technical for non-engineers"

  good:
    technical: "Connection pool exhaustion due to leaked database connections"
    non_technical: "The service ran out of database connections because some
      connections were not being properly closed after use. As traffic
      increased, the pool ran out and new requests could not connect
      to the database."

  root_cause_categories:
    code_bug: "A defect in the code caused incorrect behavior"
    configuration: "A configuration was incorrect or missing"
    capacity: "The system ran out of resources"
    dependency: "A downstream service failed"
    process: "A process was missing or followed incorrectly"
    human: "A human action caused an unintended effect"