Five whys
Five whys is a root-cause technique in which a team asks why a problem happened, then asks why of each answer, repeating until it reaches a cause it can fix. Five is a rule of thumb, not a requirement. It comes from lean manufacturing and is now used on software bugs and incidents.
The longer version
The method belongs to the Toyota Production System. It is commonly attributed to Sakichi Toyoda, whose loom works preceded Toyota Motor, and was described and popularised by Taiichi Ohno, who built the production system. Outside manufacturing it is used in incident reviews and in the retrospective after a defect reached customers.
A software example shows the shape. An export failed for a customer. Why? The job timed out. Why? The query scanned the whole table. Why? A filter added last sprint had no index. Why? The migration was reviewed without a look at the query plan. Why? The review checklist has no step for it. The first answer is the symptom, the last is a gap in the process, and the fix that follows is a checklist item, not an index alone. Each answer has to come from evidence, such as a log, a diff or a timeline, and not from the likeliest guess in the room. Had the chain stopped at a developer who forgot the index, it would have found a person and left the process that let the mistake through.
Teams run it in the incident review or the retrospective, usually with the timeline on the wall so each answer can be checked against it. Where the answers branch, the chain branches too, since an incident seldom has one cause. The exercise ends at the first cause the team can change, whether or not that took five questions.
Common questions
What is the five whys technique?
The five whys technique is a way to find the root cause of a problem by asking why it happened and then asking why again of each answer. The team repeats the question until it reaches a cause it can act on, which in practice may take three whys or seven.
Who invented the five whys?
The technique comes from the Toyota Production System and is commonly attributed to Sakichi Toyoda, with Taiichi Ohno describing it in his account of that system. The exact origin of the practice is less certain than its association with Toyota, so it is best credited to the system, not to one person.
How do you use the five whys on a software bug?
State the bug as a specific fact, ask why it occurred, and answer from evidence such as logs, code history and the incident timeline. Take each answer as the next question until the cause is something the team controls, such as a missing test, a review step or a deploy check, and record an action for it.
Does it always take exactly five whys?
Five is a guide, not a rule. Some problems reach a changeable cause after three questions, while others need more or branch into several chains. The team stops when the next why would leave the team's control, or when the answer is a fix rather than another question.
What are the limits of the five whys?
A single chain suggests one cause where an incident often has several, and the result depends on who is asking and which answer they accept. Chains that end on human error stop too early. Pairing the method with a timeline and a review of what the process allowed makes it more reliable.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.