Finding the root cause of an incident is mostly a problem of narrowing down. Hundreds of alerts may fire, dozens of services may look unhealthy, and the engineer on call has to work out which single failure started the chain. Statistical correlation helps, but correlation alone cannot tell you which of two related signals is the cause and which is the effect. Causal reasoning over a model of the system gets closer to what an experienced engineer does intuitively.
A causal graph for operations is surprisingly practical to build. Nodes represent components such as services, databases, queues and hosts, and edges represent dependencies: this service calls that one, this job reads from that queue. Much of the structure can be derived automatically from service meshes, tracing data, deployment manifests and configuration management records. Even a rough graph is valuable, because it allows an automated system to prefer an explanation in which an upstream failure propagates downward over one that requires many unrelated components to fail together.
With a graph in place, root-cause analysis becomes a ranking task. For each unhealthy component, ask whether its own symptoms can be explained by an unhealthy dependency. Components whose problems are not explained by anything upstream are the leading candidates. Combine this with timing, since a cause should usually begin before its effects, and with change data, since a recent deployment or configuration edit on a candidate component raises its likelihood considerably. The output is a short ranked list with the evidence for each candidate.
Language models contribute at the edges of this process, where unstructured information matters. They can read recent incident reports, runbooks, release notes and chat threads to supply context that the graph lacks, such as a known flaw in a library version or a previous incident with the same pattern. They can also turn the ranked list into an explanation a person can read quickly, citing the specific alerts, traces and changes that support each hypothesis. The model explains and summarises, while the graph and the statistics decide the ranking.
Keep the model honest about uncertainty. A good analysis says that the most likely cause is a connection pool exhaustion in the order service, with the supporting evidence, and also states what would change its mind. Present two or three hypotheses with confidence levels rather than a single confident verdict. When the evidence is weak or contradictory, the correct output is a request for human input along with the data gathered so far, not a guess dressed up as a conclusion.
Graphs go stale, and stale graphs mislead. Refresh dependency data continuously and record when each edge was last observed. Treat edges that have not been seen recently as low confidence. Handle shared infrastructure explicitly, because networks, DNS, identity providers and cloud regions are hidden dependencies that cause many large-scale incidents and rarely appear in application-level maps.
Evaluate the system against real history. Take past incidents with known causes, replay the telemetry from the time and check whether the right component appears in the top three candidates. Track that metric over time and examine the failures, which often reveal missing edges or poor signals. Over months, this turns root-cause analysis from a clever demonstration into a dependable capability.
The result is not an automated replacement for an experienced responder. It is a faster path to the right place to look. By combining a causal model of the system, statistical evidence and a language model that can read and explain, teams can reduce the time spent in the confusing early minutes of an incident, when every minute of uncertainty is also a minute of customer impact.