Root-cause analysis is the discipline of finding the underlying reason a system failed, rather than stopping at the symptom that first drew attention. A server returning errors, a corrupted record, or a crashed process is a symptom; the root cause is the condition that, if removed, would have prevented the failure entirely. The distinction between proximate cause (the event immediately before the failure) and root cause (the deeper condition that allowed it) is central to the practice, because fixing only the proximate cause tends to leave the system able to fail the same way again.
Google’s Site Reliability Engineering book frames troubleshooting as a structured, hypothesis-driven search rather than guesswork. It describes the process as “an application of the hypothetico-deductive method: given a set of observations about a system and a theoretical basis for understanding system behavior, we iteratively hypothesize potential causes for the failure and try to test those hypotheses.” The book’s worked case study shows investigators pursuing an incorrect theory about datastore indexing before discovering the actual root cause, a bug creating superfluous objects that degraded every request, illustrating how the first plausible explanation is often not the real one.
A classic technique for driving toward the root cause is the Five Whys, attributed to Taiichi Ohno of the Toyota Production System. The method is simply to ask “why” repeatedly, each answer becoming the subject of the next question, until the chain of causation reaches a condition worth fixing. The Lean Enterprise Institute defines it as “the practice of asking why repeatedly whenever a problem is encountered in order to get beyond the obvious symptoms to discover the root cause.” The number five is a guideline, not a rule; the point is to keep going past surface explanations.
Other tools support the same goal. Fishbone (Ishikawa) diagrams organize possible contributing causes into categories so that an investigation considers the whole space rather than fixating on one suspect. In complex systems a single root cause is often a simplification, since failures usually require several contributing conditions to align, which is why modern incident analysis tends to speak of contributing causes in the plural.
Root-cause analysis is most valuable when it is honest about systems rather than people. The same SRE practices that drive troubleshooting underpin the blameless postmortem, where the question is not who erred but what made the error possible and what change to the system would prevent the next one. Done well, it turns each failure into a durable improvement instead of a recurring incident.