Q: After a major outage, you're asked to lead the Post-Incident Review (also called a "Postmortem"). What is the SRE approach to postmortems, and what must the document contain?

SRE postmortems are blameless—they focus on systemic failures, not individual mistakes. The goal is learning and preventing recurrence, not assigning blame.

• Title and severity: Clear description and impact level (e.g., "P1: Payment API 45-minute outage").
• Summary: One-paragraph overview of what happened.
• Impact: Quantified damage—users affected, revenue lost, SLO budget consumed, duration.
• Timeline: Minute-by-minute chronology from detection to resolution:
• Root cause analysis: The "5 Whys" method or fault tree analysis to find the true systemic root cause—not "engineer made a mistake," but "the deployment pipeline lacked config validation."
• Contributing factors: What made detection slow? What made recovery harder?

A postmortem document must contain: The postmortem is shared openly across the organization. Recurring themes across postmortems indicate systemic reliability gaps.

14:02 — Monitoring alert fires for 5xx rate > 5%
   14:05 — On-call acknowledges, begins investigation
   14:12 — Root cause identified: bad config deployed
   14:15 — Config rollback initiated
   14:22 — Service fully recovered

• Action items: Each must have an owner, priority, and deadline:
• [P0] Add config validation to CI pipeline — @alice — 2 weeks
• [P1] Improve alerting threshold — @bob — 1 week
• Lessons learned: What went well, what went poorly.