SYMPTOM → WHY → CAUSE YOU CAN CHANGE
A 5 whys template is a short worksheet for one cause chain. State what you observed, ask why it happened, and let each answer become the next question until you reach a cause your team can change. Five is the usual length, not a quota. Copy the template below, or use the chain as one section of a root cause analysis template.
THE METHOD
The 5 whys is a questioning technique associated with the Toyota Production System. IT incident reviews use the same move. Write the problem as something observed — an error, a failed user action, a metric that moved — not as the cause you already suspect.
Ask why that observation is true. The answer should point at a log line, a config value, a timeline entry, or a change record. If you cannot point at anything, mark the step unverified instead of guessing. That answer is the next question.
Stop when the cause is something your team can change and another why would only restate it. Do not stop on a person's name if a system condition still explains how the mistake was possible. Five steps is a teaching convention, not proof that the fifth answer is the cause.
One chain follows one path. If the incident has two causes that do not depend on each other, write two chains. Forcing them into a single list hides one of them. The chain stays a hypothesis until the corrective action is in place and the original symptom stays gone.
WORKED EXAMPLE
The host, times, and settings below are made up so the chain can be followed from symptom to action. They are not measurements from a real outage, and they are not results from a study.
At 09:14, new VPN connections were refused. Sessions that were already connected stayed up.
The concentrator refused them. Its log at 09:14 said the license seat count was exhausted.
EVIDENCEConcentrator log: license limit reached, 09:14.A backup host still held idle sessions open from the 02:10 backup window. The session table showed those sessions sourced from that host and idle since then.
EVIDENCESession table: idle sessions owned by the backup host, idle since 02:10.The idle timeout on the concentrator is 24 hours, and the backup job runs every night. The previous night's sessions were still inside the timeout when the workday started.
EVIDENCEDevice config: idle timeout 86400 seconds. Backup schedule: nightly.During an earlier incident the global timeout was raised so long-running admin sessions would not drop. The change was never limited to that admin group.
EVIDENCEThe change record set the global timeout. No group-specific override exists.The change checklist only asked whether connectivity was restored. It did not ask which sessions the new setting applied to. That is a cause the team can change, so the chain stops here.
EVIDENCERunbook checklist: a "service restored" line, and no line for the scope of the setting.Clear the idle backup sessions and set a shorter idle timeout on the backup group the same day. Add a line to the checklist: which sessions does this setting apply to? The check is the next backup window — those sessions should not still be idle the following morning, and new user connections should succeed. If a second, unrelated failure had also been in the log, it would be a second chain, not another why on this one.
COPY IT
COPY-PASTE VERSION — PLAIN TEXT
5 WHYS ====== Problem (what was observed, when, what it affected): 1. Why? Answer: Evidence (log, config, timeline, or change record): 2. Why is that answer true? Answer: Evidence: 3. Why? Answer: Evidence: 4. Why? Answer: Evidence: 5. Why? Answer: Evidence: Stop when the cause is one you can change. Add or remove steps if the chain needs it. If the answer is still a symptom, ask why again. If the chain names a person, ask why the system allowed the mistake. Root cause: Is this a cause we can change, or still a symptom? Second independent cause (start another chain, or write "none"): Corrective action — owner — due date: How we will know it worked:
QUESTIONS
A 5 whys template is a short worksheet for one cause chain: the problem, a series of why questions where each answer becomes the next question, the evidence for each step, and the action you will take. Five is the usual length, not a requirement. Stop sooner when you reach a cause you can change, and continue if the answer is still a symptom.
Ask until the answer is a cause your team can change and each step is backed by evidence. Five is how the technique is usually taught, not proof that the fifth answer is the real cause. If the chain ends on a person's name, ask why the system allowed that mistake.
A 5 whys template covers the cause chain only. A root cause analysis template also records the problem statement, the timeline, contributing factors that are not the root cause, owners, and how the fix was checked. Use this page for the chain and the root cause analysis template for the whole incident record.
It goes wrong when a step is a guess with no evidence, when two independent causes are forced into one chain, or when the team stops at human error. Write the evidence next to each why. If the incident has more than one independent cause, write a separate chain for each. The chain stays a hypothesis until the corrective action is checked.
Yes. The template is plain text. Paste it into any document. The SolveStack app linked from this page stores investigation notes in your browser and exports Markdown, HTML, JSON, and ZIP with no account and no cloud service.