What needs to be finished first
A chronological sequence of events with timestamps is available, at least from the first symptom to stabilization.
An established postmortem setting exists or is used in the same session, so psychological safety is the norm.
What needs to be ready before start
Whiteboard or Miro board with a vertical chain of six boxes (Problem + 5 Whys); pen; timer; link to the triggering ticket or incident report.
One facilitator who guides the chain and asks neutral follow-up questions; two to five people with direct system contact (at least one engineer, one operator); a scribe who writes down every answer verbatim.
A concrete problem as one sentence with date and impact; incident ID or ticket link; relevant logs or graphs from the last 24 hours; known workarounds.
15-30 min
Write the problem sentence in the first box at the top. Five empty boxes vertically below it. Timer set to 20 min. Rule: no names, only mechanisms. Each answer becomes the starting point for the next Why question.
The one question this method answers
Which controllable cause behind the symptom can the team fix with a concrete countermeasure?
Marker: Minute
| Step | Duration | Action | Hint |
|---|---|---|---|
10-2 min | 2 min | Formulate the problem as an observable symptom: what, when, how often, and what effect. No guesses about causes. | If the sentence already contains a cause ('because X was broken'), rewrite it. Otherwise the chain starts too late. |
22-15 min | 13 min | Build the Why chain: one Why question and one answer per box, consistently focused on mechanisms instead of people. After each Why, check whether the answer can be supported by logs or data. | By the third Why at the latest, the answer should become technical or process-related. If it stays at the behavioral level, data access or system knowledge is missing. |
315-22 min | 7 min | Check the stop criterion: Is the lowest answer changeable by the team itself? If not, go back one Why or branch the path. | A chain often ends too early at 'the service is old.' That is not a controllable cause; either continue or open a second chain in parallel. |
422-30 min | 8 min | Note one to three concrete countermeasures, each with owner and target date. The countermeasure must address the identified cause, not the symptom. | If the countermeasure is 'improve monitoring', it is a detection measure, not a cause fix. Note both and keep them separate. |
What comes out at the end
Markdown or wiki entry in the incident directory with the problem sentence, numbered Why chain (question and answer per step), identified root cause, and list of countermeasures with owner and date.
Date, incident ID, and decider in the header. Add later corrections as an edit log at the end, do not overwrite. With new insights, set status to `revised` and keep the original chain.
Compact working template for 5 Whys with context, input, output artifacts, and next step.
A simple technique for moving from symptoms to underlying causes.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
On 14.05.2026 between 09:12 and 09:47 UTC, the Order API returned HTTP 500 for about 8% of checkout requests.
Recognize symptoms and steer against them
Answers contain names or roles ('because X was not careful') instead of system behavior.
Rephrase the answer: what did the system do or fail to do that allowed the error? If a person is truly relevant, ask for the missing safety net in the process.
The final answer is a factual description ('that's just how it has always been') without a leverage point.
Go at least one Why further, or branch the chain. If no controllable cause appears after seven Whys, the method is unsuitable, so use A3 or a Causal Loop Diagram.
Answers sound plausible but are guesses without log evidence.
Ask for evidence for each answer (log excerpt, graph, config line). If none is available, mark the Why as an 'unverified assumption' and plan a follow-up spike.
Several independent paths lead to the symptom, but only one is followed.
Open a second Why chain in parallel when branching is likely. Run both to the stop criterion and combine the countermeasures at the end.
The derived measure is monitoring, alerting, or a hotfix, not the cause in the chain.
Record detection and cause fix separately. For each identified root cause, define at least one measure that prevents recurrence, not just one that improves visibility.
The group quickly agrees on one answer and dissenting voices fall silent.
The facilitator explicitly asks for alternative hypotheses per step. If there is disagreement, document both paths and decide with data.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.