Postmortems#

A good postmortem learns without blaming individuals. It produces owned actions that reduce recurrence or improve detection—not generic “communicate better” platitudes.

When to Offer This Workflow#

Trigger conditions:

• SEV incidents, customer-visible outages, data-loss scares
• Near-misses worth documenting
• Need facilitation structure in a blame-prone culture

Initial offer:

Use six stages: (1) scope & audience, (2) timeline & impact, (3) root cause analysis, (4) what worked / didn’t, (5) action items, (6) communication & follow-up). Confirm internal-only vs customer-facing summary.

---

Stage 1: Scope & Audience#

Goal: Define readers (exec, engineering, CS) and redact PII or sensitive security details.

Practices#

• Blameless framing in the invite and template

Exit condition: Template chosen; owner for the final document.

---

Stage 2: Timeline & Impact#

Goal: Minute-resolution timeline in UTC: detection → onset → mitigation → resolution.

Impact#

• Users affected, duration, data integrity if relevant, SLA breach

Exit condition: Facts align with any external customer communication.

---

Stage 3: Root Cause Analysis#

Goal: Use five whys or fishbone as tools, not rituals. Separate root cause (fix that stops the class of failure) from contributing factors (process gaps, missing tests).

Practices#

• Do not name an individual as the “root cause”

Exit condition: Evidence-backed causal chain; contributing factors listed.

---

Stage 4: What Worked / Didn’t#

Goal: Reinforce positives (runbooks followed, clear comms) and negatives (missing dashboards, slow escalation).

---

Stage 5: Action Items#

Goal: Specific tickets with owners and dates; categorize prevent / detect / recover / process.

Practices#

• Avoid vague “add monitoring”—name metrics or signals

Exit condition: Items linked in the issue tracker.

---

Stage 6: Communication & Follow-Up#

Goal: Share summary internally; external postmortem only when policy requires; track completion in 30/60 days.

---

Final Review Checklist#

• Blameless tone; timeline and facts accurate
• Impact quantified where possible
• Root cause vs contributing factors distinguished
• Action items owned, dated, tracked
• Follow-up review scheduled

Tips for Effective Guidance#

• Match depth to severity; lightweight retro for minor incidents.
• Link traces, metrics, and logs in an appendix for engineers.
• Psychological safety enables honesty—leadership models it.

Handling Deviations#

• Security incidents: coordinate with legal/infosec before public detail.