Drill from the symptom of an incident, bug, or process breakdown to the underlying root cause by asking "why?" five times. Then turn the chain into action items and copy-ready Markdown for your postmortem.
The problem (symptom)
Try:
Why chain
Ask "Why did that happen?" for each previous answer. Five is a heuristic — stop when you hit a cause you can act on (the root), not when you hit a person to blame.
Root cause & corrective actions
Root cause
Add at least one why to identify a root cause.
Corrective actions
Each action should be specific, owned, and verifiable. Address the root, not the symptom.
Export
Common pitfalls
Stopping too early. "The build broke because the test failed." That's a symptom, not a cause. Why did the test fail? Why did that change ship without being caught?
Stopping at a person. "Because Alice forgot." Almost never the real root — keep going. Why was it possible for Alice (or anyone) to forget? The system, not the person, is usually the cause.
Drifting to single linear chain. Real incidents have multiple contributing causes. Use "Add another why" to branch — duplicate the row and follow a parallel chain.
Conflating cause with trigger. The trigger is what set it off this time. The cause is the latent condition that let the trigger turn into an incident.
Treating "5" as sacred. Three is fine if you're truly at a root. Seven is fine if you're not. Stop at the deepest cause you can act on.
No action items. A root cause without a corrective action is just a story. Each root must produce at least one specific, owned, dated action.