FIELD GUIDE / ROOT CAUSE ANALYSIS

DOCUMENT → ANALYZE → PREVENT

Root Cause Analysis Template

A root cause analysis template is a structured record of an incident: what failed, the evidence, the cause, and the actions that stop a repeat. This one is written for IT incidents and has six sections — problem statement, timeline, 5 whys, contributing factors, corrective actions, and follow-ups. Copy the plain-text version below, or capture the same investigation in SolveStack and export it as Markdown or ZIP.

Use the template Open SolveStack

THE TEMPLATE

Six sections. No fluff.

SECTION 01

Problem statement

One paragraph: what happened, what was affected, and when it was detected. Write it so someone who was not on call can understand the incident in thirty seconds. Include the blast radius — users, systems, or business process — with the measurements you actually have, not adjectives.

ILLUSTRATIVE EXAMPLEPayment API returned HTTP 500 for a slice of checkout requests, 14:02–14:47 UTC. Failed orders were counted from the checkout log. Detected by the checkout-error alert, not by a customer report.

SECTION 02

Incident timeline

A timestamped sequence from first symptom to confirmed resolution. Record what was observed and what was done at each step — including the dead ends. The timeline is the evidence the rest of the analysis stands on. An RCA without one is a guess.

ILLUSTRATIVE EXAMPLE14:02 — alert fires. 14:09 — on-call confirms 500s on /pay/confirm. 14:18 — database primary disk at 100% found. 14:31 — disk expanded, errors stop. 14:47 — error rate back to baseline, incident closed.

SECTION 03

The 5 whys

Ask "why" repeatedly — typically five times — with each answer becoming the next question. Write each why down. The chain is the deliverable, not just the final answer. Stop on a cause you can change, and keep a note of the evidence for each step. For the chain on its own, use the 5 whys template.

ILLUSTRATIVE EXAMPLEWhy did checkout fail? The database rejected writes. Why? Its disk was full. Why? Log retention had no cap. Why? The retention policy was never configured after the migration. Why? The migration runbook had no storage-verification step.

SECTION 04

Contributing factors

Conditions that made the incident worse or more likely, but are not the cause the chain ends on. Keep them in this list so they are not mistaken for the root cause. A contributing factor can still deserve an action.

ILLUSTRATIVE EXAMPLEThe disk alert fired late enough that there was little time to act. Staging had more disk headroom than production, so load tests never reached a full disk. The rollback step in the runbook assumed a healthy database.

SECTION 05

Corrective actions

Every action gets an owner and a date. An action without both is a wish. Separate immediate fixes (stop the current impact) from systemic fixes (stop the recurrence). If an action cannot be scheduled, say so explicitly rather than letting it drift.

ILLUSTRATIVE EXAMPLEImmediate: cap log retention (Priya, this week). Systemic: add a storage-verification step to the migration runbook (Marcus, next sprint). Systemic: page on disk growth earlier (Priya, next sprint).

SECTION 06

Follow-ups

Close the loop: did the corrective actions happen, and did they work? Record the check — the test, metric, or review that showed the fix held. An RCA whose actions were never checked is unfinished.

ILLUSTRATIVE EXAMPLERetention cap deployed; disk growth stayed flat over the following two weeks. Runbook updated and reviewed in the next ops review. The earlier disk alert fired once on a real growth spike.

COPY-PASTE VERSION — PLAIN TEXT

ROOT CAUSE ANALYSIS
===================
Incident:
Date (start–end, with timezone):
Severity:
Incident commander:
Systems affected:

1. PROBLEM STATEMENT
   What failed, what it affected, and when it was detected.
   Measurements you actually have (counts, durations, error rates):

2. INCIDENT TIMELINE
   HH:MM TZ — what was observed or done
   HH:MM TZ —
   HH:MM TZ — resolution confirmed

3. THE 5 WHYS
   Problem:
   1. Why?
      Answer:
      Evidence:
   2. Why?
      Answer:
      Evidence:
   3. Why?
      Answer:
      Evidence:
   4. Why?
      Answer:
      Evidence:
   5. Why?
      Answer:
      Evidence:
   Root cause (a cause you can change):
   Add another chain if a second cause does not depend on this one.

4. CONTRIBUTING FACTORS
   - Factor — how it made the incident worse or more likely, and why it is not the root cause

5. CORRECTIVE ACTIONS
   - [ ] Immediate: action — owner — due date
   - [ ] Systemic: action — owner — due date

6. FOLLOW-UPS
   - Action — date checked — what showed it worked

RUN IT LOCALLY

Document the investigation where it happens.

A template is only as good as the evidence behind it. SolveStack gives an IT investigation a durable 7-part structure while the work is still happening — then exports the whole record as portable files.

Open SolveStack See export formats

The original symptom — what the problem statement is built from
Commands and observations — the raw material of the timeline
Evidence — logs, screenshots, and attachments captured as you go
Competing hypotheses — written down before you commit to one
Causes ruled out — the dead ends, preserved instead of forgotten
The confirmed root cause — what the 5 whys converge on
The validation — proof the resolution actually worked

QUESTIONS

RCA, answered briefly.

What is a root cause analysis template?

A root cause analysis template is a structured document that walks an incident from the symptom to a confirmed cause. This one has six sections: problem statement, timeline, 5 whys, contributing factors, corrective actions, and follow-ups. Filling it in keeps the analysis tied to evidence instead of turning it into a blame exercise.

What are the 5 whys?

A technique where you ask why repeatedly, usually about five times, and each answer becomes the next question. It moves the analysis past a surface symptom, such as the server crashed, to a cause you can change, such as no alert on disk growth. The 5 whys template is a shorter worksheet for that chain alone.

How do I write a root cause analysis for an IT outage?

Start with a precise problem statement and a timestamped timeline. Apply the 5 whys to the timeline, separate contributing factors from the root cause, record corrective actions with owners and dates, then check that the fix worked.

What is the difference between a root cause analysis and a postmortem?

A root cause analysis is the work that identifies why an incident happened. A postmortem, or post-incident review, is the broader document: timeline, impact, the analysis itself, and action items. Teams often keep both in one record.

How is a 5 whys template different from a root cause analysis template?

A 5 whys template records only the cause chain. A root cause analysis template also records the problem statement, the timeline, contributing factors, owners, and whether the actions worked. Use the shorter worksheet for the chain, and this page for the full incident record.

Can I use this template offline?

Yes. The template is plain text you can copy into any document. SolveStack, the app linked from this page, also works offline: investigation data stays in IndexedDB in your browser, with no account and no cloud service.