Automated root cause analysis

At a glance

Method	What it ranks	Where it breaks
Runbook and human search	Whatever the responder checks first	Depends entirely on who is on call that night
Log clustering	Messages that spiked together	Surfaces the loudest service, which is often a victim rather than the cause
Metric correlation	Series that moved together	Every service moves together during a real incident
Topology-aware correlation	Connected services that moved together	Still ranks co-movement, so simultaneous changes stay tied
Causal inference over a versioned graph	The change whose effect reached the symptom	Needs dependency history, not just current topology

How it works

Every automated RCA system does the same three things in some form: build a model of the system, detect that something is wrong, and search the model for an explanation. The differences are entirely in the third step, and they follow from what the model contains.

A model built from metrics alone can only rank co-movement. A model that adds topology can restrict that ranking to services that are actually connected, which removes obvious false positives but does not separate two changes that landed in the same minute on the same path. A model that records how topology changed over time can ask a different question: not what moved with the symptom, but what change has a path to it that did not exist before.

That last question is the one that returns a named deploy, config change or resource event rather than a shortlist. It is also the one that requires the most from the data layer, because it needs the dependency graph as it was at 14:02, not as it is now. How causal AI finds a root cause covers the inference side in detail.

The detection step matters more than it looks. A system that only starts investigating when a threshold alert fires inherits that alert's blind spots, and the slow-burning failures that cost the most are exactly the ones no threshold catches. Systems that investigate continuously rather than on a page find a different class of incident.

How it is measured

The measurement is Top-1 accuracy on incidents whose true cause is known independently, and the honest version of it is harsh. The system's ranked first answer either matches the real cause or it does not.

RCAEval, a public fault-injection benchmark from the ACM Web Conference in 2025, runs this over 735 injected faults. Correlation-based methods score between 17 and 42 percent across twelve academic baselines. A causal method reaches 89 percent, recorded in the AI SRE Benchmark.

Two measurements are commonly substituted and neither answers the question. Top-5 accuracy tells you the cause was somewhere in the list, which is what the responder had before the tool. Mean time to resolution is an outcome that moves for many reasons, including process changes made at the same time as the purchase, so it cannot isolate the diagnosis.

Reproducing this on your own estate is straightforward and worth the afternoon: take twenty resolved incidents whose cause is recorded in the postmortem, replay them, and count first answers.

Common misconceptions

That noise reduction is root cause analysis. Grouping fifty alerts into three is genuinely useful and it is a different claim. It shortens the list a human searches rather than completing the search.

That the loudest signal is the cause. The service emitting the most errors is frequently downstream of the problem. Ranking by volume systematically points at victims.

That a confident narrative is an answer. A system that explains its reasoning fluently and names the wrong change is worse than one that abstains, because the explanation is what makes the responder stop looking.