Root Cause Analysis Methods: 5 Whys, Fishbone and Timelines

Root cause analysis is the family of techniques used to work out why something happened, so that the same thing is less likely to happen again. The label is slightly misleading, since complex failures rarely have one root. The methods remain useful as ways to organise the evidence and the thinking. Four are in common use.

Timeline analysis

Build an ordered list of what happened, with times: changes, alerts, actions and observations. Start with the scribe's record and add logs and change records. A timeline shows sequence, delays and gaps between an event and its detection. It is the base for every other method, and often it is enough, because the answer is visible once the events sit in order.

Its weakness is that it records what was noticed. Events nobody recorded are missing, so check for gaps and ask what else was happening.

5 Whys

Ask why the failure happened, then why that happened, and continue, typically five times, until you reach a condition you can change. For example: the site was down because the database ran out of disk. Why? A table grew without limit. Why? A cleanup job was failing. Why was nobody told? The alert for failed jobs went to an unused channel. Why? The channel was never updated after a reorganisation.

It is quick and needs no tools. Its weakness is that it follows a single chain, so it can hide parallel causes, and the answer depends on who is asking. Use it to deepen a single branch, not as the whole analysis. Avoid questions that end in a person. Ask what made the mistake possible.

Fishbone diagram

A fishbone, or cause and effect, diagram places the failure at the head and groups possible contributors on branches by category, such as people, process, tools, environment and dependencies. It helps a group generate ideas broadly and sort them. Its weakness is that it records possibilities, not evidence, so each branch needs checking against the facts.

Fault tree

A fault tree works backwards from the failure, breaking it into the combinations of events that could produce it, joined by AND and OR. It suits systems with redundancy, where several things must fail together. It is more laborious, and it is best reserved for serious or safety-relevant failures.

Choosing and combining

• Always start with a timeline.
• Use 5 Whys on each significant branch, with several people so that different chains emerge.
• Use a fishbone when the group is stuck or the failure has no obvious path.
• Use a fault tree when redundancy was defeated and you need to know how.
• Record the result as contributing factors, not as one cause.

Keep the analysis blameless

Whichever method you use, aim it at the system. A conclusion of human error is the start of the analysis. Ask what made the error easy to make and hard to notice. Atlas incident reviews reflect this: they record contributing factors, refuse publication below two, and have no root cause field.