5 Whys Analysis: How to Find Root Cause (with Examples)
The 5 Whys explained — how the technique works, a step-by-step process, worked manufacturing examples, common pitfalls, and how it fits with other RCA tools.
The 5 Whys is a root cause analysis technique that repeatedly asks "Why?" — typically five times — to trace a visible problem backward through its chain of causes until the fundamental, systemic root cause is reached. Developed by Sakichi Toyoda and embedded in the Toyota Production System, it is the fastest way to move a team from "the machine stopped" to "here is what we must permanently fix."
A complete 5 Whys analysis produces three outputs: a verified root cause, a corrective action that eliminates that root cause, and a preventive action that stops similar causes from arising elsewhere. Without all three, the exercise is incomplete.
What the 5 Whys Is
The 5 Whys is a causal interrogation method — not a brainstorming session, not a blame exercise, and not a checklist. Each answer to "Why?" becomes the subject of the next question, forming a single chain of cause and effect that terminates at a root cause: a systemic condition that, if corrected, prevents the original problem from recurring.
The number five is a rule of thumb, not a law. Some problems resolve in three iterations; others require seven. What matters is reaching a cause that is actionable and systemic — something the organization can change — rather than stopping at a symptom ("the bearing failed") or an individual ("the operator didn't check the level").
The technique sits within the broader discipline of root cause analysis. It is the simplest RCA tool available and the appropriate starting point for the majority of equipment faults, quality escapes, and process deviations encountered in day-to-day manufacturing and automation environments.
How It Works
The mechanism is straightforward: state the problem precisely, then ask "Why did this happen?" Write the answer. Ask "Why did that happen?" Write the answer. Continue until you reach a cause that:
- Is under organizational control — a policy, procedure, standard, maintenance practice, or design decision that can be changed.
- Explains the full chain above it — removing this cause would have prevented every link in the chain.
- Does not have a useful further "Why?" — the next answer would be outside the organization's sphere of influence, or would lead to a different problem entirely.
A well-formed chain reads naturally from bottom to top: Because [root cause] → [cause n] → ... → [cause 1] → [problem].
Step by Step: How to Do a 5 Whys Analysis
Step 1 — State the problem precisely
Vague problem statements produce vague causes. Describe the observable failure in specific, factual terms: what happened, when, where, and to what extent. Avoid embedding causes or judgments in the problem statement.
Weak: "The line keeps going down." Strong: "Conveyor C-07 tripped on overcurrent fault at 14:23 on 2026-06-16, causing a 47-minute unplanned stoppage."
Step 2 — Assemble the right people
Include operators, maintenance technicians, and the process or controls engineer who knows the system. Frontline knowledge is essential — the people closest to the failure hold evidence that does not appear in any report.
Step 3 — Ask "Why?" and record each answer as a factual statement
Base each answer on evidence: inspection findings, sensor logs, maintenance records, PLC fault buffers. Avoid assumption. If you do not know the answer yet, that is a data-collection action before proceeding.
Step 4 — Test the chain
Read the chain back from root cause to problem using "therefore" logic. If any link does not hold — if the cause listed does not reliably produce the effect above it — the chain has an error and must be corrected.
Step 5 — Identify the root cause and assign countermeasures
The last verified cause is the root cause. Define a corrective action (what will be done to fix this root cause permanently) and a preventive action (what will be done to prevent the same root cause from appearing in related systems or processes). Assign an owner and a target date for each.
Step 6 — Verify effectiveness
After the countermeasure is implemented, confirm the problem has not recurred. If it recurs, the root cause identification was incomplete and the analysis must be restarted with the new evidence.
A Worked Manufacturing Example
Problem statement: Production line 4 stopped at 06:47 on 2026-06-15. Root cause analysis required.
| # | Why? | Answer (evidence) |
|---|---|---|
| 1 | Why did the line stop? | The conveyor motor tripped on thermal overload. |
| 2 | Why did the motor overheat? | It was running at elevated current for approximately 90 minutes before the trip. |
| 3 | Why was current elevated? | A bearing in the tail-pulley assembly had seized, increasing drag on the belt. |
| 4 | Why had the bearing seized? | The bearing housing showed no evidence of lubrication — the grease nipple was blocked with hardened grease. |
| 5 | Why was the grease nipple blocked? | The lubrication frequency in the preventive maintenance schedule had not been updated when the conveyor speed was increased six months prior; higher speed requires more frequent lubrication. |
Root cause: The PM schedule was not reviewed after an operational change (speed increase), leaving the lubrication interval misaligned with actual wear rate.
Corrective action: Clear and re-grease all tail-pulley bearings on Line 4. Implement a maintenance engineering sign-off step whenever conveyor speed parameters are changed.
Preventive action: Audit PM schedules for all conveyors against current operating parameters. Add "PM schedule review" to the management-of-change (MOC) checklist.
A Worked Automation Example Using PLC Fault Data
One of the most powerful applications of the 5 Whys in modern manufacturing is using PLC diagnostic data as evidence at each step. The fault buffer, alarm history, and I/O status logs in a PLC provide a timestamped, objective record that replaces speculation with fact.
Problem statement: Packaging line 2 declared a safety stop (E-stop category 1) at 22:14 on 2026-06-14, causing a 2-hour stoppage and product loss.
| # | Why? | Answer (PLC/SCADA evidence) |
|---|---|---|
| 1 | Why did the safety stop trigger? | PLC fault buffer shows Safety Input SI-04 (guarding door switch, Station 6) opened at 22:14:03. |
| 2 | Why did the door switch open mid-cycle? | Alarm history shows SI-04 had 14 momentary open events in the prior 8 hours — not logged as faults because each reset within 200 ms. Maintenance call-out was not triggered. |
| 3 | Why was SI-04 intermittent? | Physical inspection of Station 6 door shows the switch actuator bracket had cracked. The door was vibrating enough to cause intermittent contact loss, but not enough to hold the switch open until 22:14. |
| 4 | Why had the bracket cracked? | The bracket is a mild-steel fabrication. A design review note from 2024 recommended upgrading to stainless at next planned overhaul; the overhaul was deferred twice and the upgrade was never completed. |
| 5 | Why was the deferred maintenance not tracked to completion? | The corrective action was recorded in a paper maintenance log rather than the CMMS. When the overhaul was rescheduled, the paper log item was not transferred; it was effectively lost. |
Root cause: Corrective actions arising from engineering design reviews are not captured in the CMMS, so they are lost when physical logs are not transferred during schedule changes.
Corrective action: Replace bracket on Station 6 with stainless-steel design. Enter all open design-review corrective actions into the CMMS immediately.
Preventive action: Mandate that all engineering review action items are logged in the CMMS at the time of creation, with a review gate that prevents closure of a design review record until all actions are tracked. Update the PLC troubleshooting procedure to flag recurring momentary faults (more than five resets in four hours) as a maintenance work order trigger.
This example illustrates why PLC fault data is so valuable in the 5 Whys process. Without the alarm history showing 14 prior events, the team would have investigated only the final trip — likely concluding the switch simply failed — and missed the deferred maintenance chain entirely.
When 5 Whys Is Enough vs. When to Use Fishbone or Fault Tree
The 5 Whys is the right tool when:
- The problem has a single dominant cause chain — one sequence of events explains the failure.
- The team has direct knowledge of the system — they can answer each "Why?" from evidence rather than theory.
- Speed matters — a team can complete a solid 5 Whys in 30 to 60 minutes for a well-understood failure.
- The problem is operational in nature — equipment failures, quality deviations, process upsets.
Use a fishbone diagram (Ishikawa diagram) when:
- The problem has multiple potential cause categories that need to be explored simultaneously (machine, method, material, man, measurement, environment).
- The team needs a structured brainstorming framework to ensure no category of cause is overlooked.
- You want to generate hypotheses before narrowing to a root cause via evidence.
Use a fault tree analysis (FTA) when:
- The failure involves complex system interactions where multiple independent faults must coincide to produce the top event.
- Safety-critical systems are involved and formal quantitative probability analysis is required.
- The problem is a designed system being evaluated proactively (before failure), not reactively.
- Regulators or customers require a documented, logical deductive analysis.
In practice, these tools complement each other. A fishbone generates candidates; the 5 Whys drills into the most likely candidate; FTA validates complex interactions for high-consequence failure modes. For a full comparison of methods, see the root cause analysis guide.
Common Pitfalls
Stopping at a symptom, not a root cause
The most frequent error is accepting an intermediate cause as the final answer. "The bearing failed" is a symptom. "The lubrication schedule was not updated after an operational change" is a root cause. The test: can the organization change something to prevent this cause from occurring? If the answer is "no, bearings just fail," the analysis has not gone far enough.
Single-path bias
The 5 Whys naturally produces a single linear chain. Real failures often have contributing factors that branch off the main chain. If the analysis stops at one path, a significant contributor may be missed. When reviewing answers, ask whether there are parallel causes that also need to be addressed. If there are multiple branches, consider whether a fishbone diagram is a better organizing framework before narrowing with the 5 Whys.
Blaming people instead of systems
"The operator forgot to check the level" is not a root cause. It is a symptom of a system that relies on human memory rather than engineered controls. The correct next question is: "Why was a manual check the only safeguard?" The 5 Whys should always terminate at a system, process, or design failure — not at an individual. This is not about avoiding accountability; it is about identifying changes that actually prevent recurrence. People make errors; robust systems catch those errors before they cause failures.
Answers based on assumption, not evidence
Each link in the chain must be supported by physical evidence, data, or direct observation. When a team cannot answer a "Why?" with evidence, the correct action is to gather the evidence — inspect the component, pull the fault log, review the maintenance record — before continuing. Assumption-based chains lead to incorrect root causes and ineffective countermeasures.
No countermeasure verification
A 5 Whys analysis that does not include a follow-up check on countermeasure effectiveness is unfinished. The root cause is a hypothesis until corrective actions are implemented and the problem does not recur. Schedule a review 30 to 90 days after implementation.
5 Whys and Countermeasures
The full value of the 5 Whys is only realized when the root cause is connected to permanent countermeasures — actions that change the system so the root cause cannot produce the same problem again.
A structured countermeasure table clarifies ownership and tracks progress:
| Root Cause | Corrective Action | Preventive Action | Owner | Target Date | Verification Date |
|---|---|---|---|---|---|
| PM schedule not reviewed after speed change | Update conveyor C-07 PM schedule; re-grease bearings | Add MOC trigger requiring PM schedule review on all parameter changes | Maintenance Supervisor | 2026-06-25 | 2026-07-25 |
Countermeasures at different levels of the causal chain are sometimes warranted. A corrective action at Why 3 (fix the immediate physical cause) combined with a preventive action at Why 5 (fix the systemic cause) gives defense in depth. The goal is always the systemic fix; the immediate fix simply restores production while the systemic fix is implemented.
For equipment-intensive environments, connecting countermeasures to FMEA entries is good practice. The root cause identified in a 5 Whys investigation is often a failure mode that was not captured — or was captured but assigned too low a probability — in the existing FMEA. Feeding it back closes the loop.
Frequently Asked Questions
What is the 5 Whys technique? The 5 Whys is a root cause analysis method developed by Sakichi Toyoda for the Toyota Production System. It works by asking "Why did this problem occur?" repeatedly — typically five times — following each answer as the next question's subject. The goal is to move from a visible symptom to the underlying systemic cause that, when corrected, prevents recurrence.
How do you do a 5 Whys analysis? State the problem precisely in factual terms. Gather the team with direct knowledge of the system. Ask "Why?" and record the answer as a fact supported by evidence — inspection findings, sensor data, maintenance logs. Ask "Why?" of that answer. Repeat until you reach a cause that is systemic, actionable, and fully explains the chain above it. Assign corrective and preventive actions with owners and target dates. Verify effectiveness after implementation.
What is an example of 5 Whys? A conveyor motor trips on thermal overload (Why 1: motor overheated; Why 2: bearing seized, increasing drag; Why 3: bearing had no lubrication; Why 4: grease nipple was blocked; Why 5: lubrication frequency was never updated after conveyor speed was increased). Root cause: operational changes are not triggering PM schedule reviews. Countermeasure: add PM review to the management-of-change checklist.
What are the limitations of 5 Whys? The 5 Whys produces a single causal chain and can miss parallel contributing factors. It depends on the team's willingness and ability to answer each "Why?" with evidence rather than assumption. It is less suitable for complex, multi-path failure scenarios where fault tree analysis or a fishbone diagram provides better structure. It also tends to underperform when the team does not include people with direct knowledge of the system, since assumptions fill the gaps where evidence should be.
