Incident postmortem
A structured analysis after a serious operational incident: what happened, why, how it was resolved, and what should change so it doesn't recur. Modern practice emphasizes that it should be blameless — focused on system failures, not pointing out a scapegoat.
Contents: a timeline (what happened when), impact (how many were affected, for how long), root cause analysis (the underlying causes, not just the symptom), and — most importantly — concrete action items with owners to prevent recurrence. Blameless is the core: if people are punished for mistakes they hide problems and don't report → you never learn the real causes. The assumption is that people acted reasonably given what they knew, and that if a single person's mistake could cause an outage, it's the SYSTEM (a lack of guardrails, poor design) that should be fixed. Popularized by Google's SRE book and Etsy. A learning, not a blame, culture. Tightly tied to SLOs, error budgets, and runbooks. Related to SLO/SLI and toil reduction.