Root Cause Analysis Template
Incident: {{ incident_title }} Date: {{ incident_date }} Summary: {{ incident_summary }}
Method 1: 5-Whys Analysis
Start with the problem statement and ask "Why?" iteratively until you reach the root cause. Typically 3-7 levels deep.
Problem Statement
{{ incident_summary }}
Why Chain
| Level | Question | Answer | Evidence |
|---|---|---|---|
| Why 1 | Why did [problem] occur? | answer | link to logs/metrics |
| Why 2 | Why did [answer 1] happen? | answer | evidence |
| Why 3 | Why did [answer 2] happen? | answer | evidence |
| Why 4 | Why did [answer 3] happen? | answer | evidence |
| Why 5 | Why did [answer 4] happen? | answer | evidence |
5-Whys Best Practices
- Each "Why" must be supported by evidence, not speculation
- If you branch (multiple answers to one "Why"), follow each branch
- Stop when you reach a cause that is actionable and within your control
- The root cause should be a process, system, or design flaw — not a person
Method 2: Ishikawa (Fishbone) Diagram
Organize contributing factors across six categories:
Categories and Contributing Factors
People
- Insufficient training or documentation
- Cognitive overload / fatigue
- Unfamiliarity with the system
- Communication breakdown
- Additional factors:
Process
- Missing or inadequate runbook
- Change management gaps
- Insufficient review process
- Missing pre-deployment checks
- Additional factors:
Technology
- Software bug or regression
- Infrastructure failure
- Capacity limitation
- Missing monitoring or alerting
- Additional factors:
Environment
- External dependency failure
- Network conditions
- Cloud provider issue
- Traffic pattern anomaly
- Additional factors:
Measurement
- Insufficient observability
- Missing SLIs/SLOs
- Alert threshold misconfiguration
- Delayed detection
- Additional factors:
Design
- Single point of failure
- Missing circuit breaker
- Inadequate retry/backoff logic
- Tight coupling between services
- Additional factors:
Method 3: Fault Tree Analysis
Work backwards from the top-level failure event using AND/OR logic gates.
Top Event
{{ incident_summary }}
Fault Tree Structure
[Top Event: Service Failure]
├── OR ──┬── [Intermediate Event 1]
│ │ ├── AND ──┬── [Basic Event A]
│ │ │ └── [Basic Event B]
│ │ └── [Basic Event C]
│ │
│ └── [Intermediate Event 2]
│ ├── [Basic Event D]
│ └── [Basic Event E]
Fill in the fault tree with actual events:
| Event ID | Type | Description | Probability | Preventable |
|---|---|---|---|---|
| TOP | Top Event | {{ incident_summary }} | — | — |
| IE-1 | Intermediate | description | — | — |
| IE-2 | Intermediate | description | — | — |
| BE-A | Basic Event | description | low/med/high | yes/no |
| BE-B | Basic Event | description | low/med/high | yes/no |
Root Cause Classification
Classify the identified root cause(s):
| Category | Root Cause | Confidence | Actionable |
|---|---|---|---|
| process/technology/design | description | high/medium/low | yes/no |
Root Cause vs. Contributing Factor
- Root cause: The fundamental reason the incident occurred; removing it would have prevented the incident
- Contributing factor: Something that made the incident worse, slower to detect, or harder to resolve; removing it alone would not have prevented the incident
Corrective and Preventive Actions
Corrective Actions (fix the immediate problem)
| Action | Owner | Priority | Due Date | Ticket |
|---|---|---|---|---|
| action | name | P1/P2/P3 | date | link |
Preventive Actions (prevent recurrence)
| Action | Owner | Priority | Due Date | Ticket |
|---|---|---|---|---|
| action | name | P1/P2/P3 | date | link |
Detection Improvements (find it faster next time)
| Action | Owner | Priority | Due Date | Ticket |
|---|---|---|---|---|
| action | name | P1/P2/P3 | date | link |
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |