Use Incident Postmortem Prover with your AI.

Validate incident postmortem

A postmortem that stops at "the server crashed" is a narrative, not an investigation. You must: (1) reconstruct the TIMELINE minute-by-minute in UTC. every alert, page, action, decision, and escalation. If you cannot account for a 5-minute gap, that gap hides a process failure, (2) apply 5 WHYS until you reach an organizational or systemic root. "server crashed" is Why #0. Why crashed? Why THAT? Why THAT? Keep going until you reach a process, incentive, or cultural root cause, (3) SEPARATE root cause from contributing factors. root cause ENABLES, factors AMPLIFY. "Multiple causes" is a dodge. There is one enabling cause and several amplifiers, (4) write ACTION ITEMS with ODAS: [Owner] [Deadline] [Specific Action] [Success Metric]. "Add monitoring" will be forgotten. An owner, a date, an action, and a measurable success criterion will not, (5) cross-reference INCIDENT HISTORY for recurrence patterns. same service, same cause type, same window, same team. "First time" requires evidence. If rejected, your postmortem is a narrative, not an investigation. Structured reflection capability for rigorous incident postmortem analysis. forces minute-by-minute timeline reconstruction, 5 Whys chain to systemic root cause, root cause isolation from contributing factors, owner-deadline-metric action items, and recurrence pattern analysis. Catches Timeline Incomplete (narrative summary instead of minute-by-minute reconstruction. "the site went down for about an hour" is a story. "14:32 UTC. PagerDuty alert fires. 14:33. @bob paged. 14:35. Joins #incident-123. 14:38. Identifies crash loop in payment-svc. 14:42. Rollback v2.4.1→v2.4.0 initiated. 14:45. Service recovered" is an investigation. Every minute unaccounted for is a gap in the investigation), Shallow Whys (stopping at the surface symptom instead of reaching systemic root cause. "the server crashed" is Why #0, not a root cause. Why crashed? → OOM. Why OOM? → Memory leak. Why leak? → No integration test on payment→inventory path. Why no test? → Testing culture prioritizes unit tests. Why? → Team incentives reward feature velocity. THAT is a root cause. an organizational incentive structure), Root Cause Confused (conflating root cause with contributing factors. "multiple causes" is a dodge. There is ONE root cause that ENABLES the incident. Contributing factors AMPLIFY but do not cause. Friday deploy is a contributing factor. it did not cause the bug, it reduced staffing to catch it. Root cause: no integration test. Contributing: Friday deploy, high alert threshold, outdated runbook), Actions Vague ("add monitoring" without owner, deadline, or success metric. "improve testing" is a wish, not an action item. "[@alice] [By: 2024-03-15] [Deploy connection pool metric alert at 80% threshold] [Success: alert fires in staging within 30 seconds of threshold breach]" is actionable. Every action item without ODAS (Owner-Deadline-Action-Success) will be forgotten), and Pattern Ignored (treating every incident as unique without cross-referencing history. "first time this happened" requires evidence from the incident database. Same service in 6 months? Same root cause type? Same deploy window? Same team? If no incident database exists, that IS the first action item). Call once per incident postmortem or root cause analysis