Root cause analysis has always involved a certain amount of detective work. Something breaks, alerts start firing, dashboards turn red, and engineers work backwards through logs, traces, configuration changes and dependencies until they can explain what actually went wrong. Sometimes that takes minutes. Sometimes it takes most of the night.
Automated root cause analysis promises to cut much of that work out. Instead of an engineer manually joining the dots between thousands of operational signals, AIOps platforms can analyse them together, identify patterns and present the most likely cause. Increasingly, they can also recommend what should happen next.
The speed gains can be enormous and two systems presented at ACM SIGCOMM 2026 show how quickly automated RCA is advancing. AIDA, an automated RCA system deployed in Alibaba Cloud, achieved 95.4 per cent precision and reduced median diagnosis time for network device failures from 72.6 hours to 1.6 minutes.
Another production system, XiHe, has assisted with more than 3,000 incidents while achieving 94.6 per cent overall accuracy. But faster diagnosis creates a different question for infrastructure teams. If an AI system says it has found the root cause, how do you know when to believe it?
More importantly, when is the evidence strong enough to justify letting that diagnosis influence a production environment?
Faster Root Cause Analysis Changes The Trust Problem
Automated RCA isn't new. AIOps platforms have been correlating alerts, identifying anomalies and helping engineers narrow down incidents for years. What's changing is how far that analysis can now travel through the incident response process before someone takes over.
AWS DevOps Agent, for example, can automatically investigate an incident using metrics, logs, traces, code changes and deployment history. Once it identifies a root cause, it can generate mitigation proposals that include the recommended action, its expected outcome and any prerequisites before an operator decides whether to apply it.
ServiceNow has moved further. Its AIOps AI Specialist can autonomously analyse alerts, investigate their impact and hand incidents to a remediation agent capable of executing predefined fixes. Splunk's AI troubleshooting agent now connects automated RCA with guided remediation plans for application performance and Kubernetes alerts.
That changes what getting the diagnosis wrong actually means. If an RCA system simply suggests where an engineer should investigate, a bad answer may waste some time. Once the same conclusion determines whether infrastructure gets restarted, reconfigured, isolated or rolled back, being convincingly wrong can have much larger consequences.
So RCA maturity can't be measured by speed or accuracy alone. Infrastructure teams also need to know what sits between the answer the system generates and the action they're being asked to trust.
A Plausible Explanation Isn't The Same As Evidence
Generative AI is very good at explanation. Give a model enough operational context and it can produce a detailed account of what appears to have happened, why a service failed and which change probably caused it. The problem is that sounding coherent doesn't prove the reasoning is correct.
Imagine an automated RCA system reports that a deployment increased memory pressure in one service, which raised latency in another and eventually caused requests to fail. That's a perfectly reasonable causal story. An engineer still needs to know whether each part of that story is supported by what happened in the environment.
AIDA was designed specifically around this problem. Its researchers found that existing machine learning and large language model approaches could be too coarse or fail to produce the verifiable reasoning operators need. Instead, AIDA turns expert reasoning into interpretable chains and an evolving knowledge graph that guides the model through its diagnosis.
XiHe approaches the problem differently but arrives at much the same place. Its multi-agent architecture uses evidence-driven investigation and a causality representation to build transparent causal graphs, rather than giving operators only a final root-cause label. The researchers explicitly describe verifiable interpretability as necessary for operator trust.
That's an important distinction for infrastructure teams evaluating automated RCA. An explanation helps someone understand what the system thinks happened. Evidence gives them something they can challenge. As these tools take on more operational responsibility, the second becomes increasingly important.
Correlation Can Point To The Wrong Root Cause
Modern infrastructure generates an extraordinary amount of correlated information. A failed dependency might increase application latency, trigger retries, overload another service, exhaust a connection pool and set off dozens of alerts. All of those symptoms belong to the same incident, but only one may tell you where it actually started.
Finding things that changed at roughly the same time isn't the same as proving one caused the other. This is particularly difficult in distributed systems, where a fault can travel through several dependencies before creating the symptom that finally gets someone's attention. Research published in Computers, Materials & Continua in May 2026 describes one consequence as causal confusion.
When large language models rely heavily on textual patterns rather than underlying system structure, they can mistake a prominent downstream symptom for the root cause that created it. Researchers are increasingly addressing this by combining AI reasoning with structured information about relationships.
EvoCause, published in July 2026, uses an LLM to propose changes to a causal graph, but deterministic code validates those changes before they're accepted. The final graph can then produce transparent RCA predictions without an LLM being involved at diagnosis time. That hybrid approach is interesting because it doesn't ask AI to do everything.
The model helps where semantic reasoning is useful, while more predictable mechanisms constrain what gets accepted as true. In other words, probabilistic reasoning gets deterministic anchors.
For infrastructure teams, the lesson is fairly practical. Supporting telemetry isn't enough if an RCA platform can't show how the suspected failure travelled through the systems involved. The evidence needs relationships as well as observations.
Trustworthy RCA Needs An Evidence Trail
A useful automated diagnosis should therefore be more than a root-cause statement with a confidence score attached. It should leave an evidence trail that an operator can follow back through the environment and use to decide whether the conclusion holds.
Splunk's current implementation gives us one example of what this begins to look like in a commercial platform. Its troubleshooting agent provides suspected root causes alongside an evidence view containing relevant logs, exemplar traces and related application information. It also calculates relative confidence according to the supporting evidence available.
But evidence isn't simply about attaching more data to the answer. More telemetry can create a bigger pile to inspect without making the diagnosis any easier to trust. What operators need is enough context to understand where the conclusion came from, how the pieces connect and where uncertainty remains.
What supports the diagnosis?
The first question is the simplest: what actually supports this conclusion? An engineer should be able to move from the root-cause statement back to the logs, metrics, traces, alerts, infrastructure events or configuration changes the system used to reach it.
That connection also needs to be specific. If a deployment is identified as the likely trigger, the operator should be able to confirm that it occurred at the relevant time and affected the component involved. If a resource constraint is blamed, the corresponding telemetry should show the change.
This is partly an observability problem, but it's also a data association problem. Splunk's own guidance notes that its RCA performs best when logs, services, traces and infrastructure resources share enough identifying context for the system to connect them reliably. Missing or poorly mapped information can cause relevant evidence to be overlooked.
So an organisation can buy increasingly sophisticated automated RCA and still get weak answers if the underlying operational information doesn't join together properly. Better reasoning can't compensate for evidence the system never received or couldn't associate with the incident.
How does the failure connect?
The next question is how the suspected cause connects to everything that happened afterwards. This is where topology and dependency information become particularly valuable because an incident rarely stays neatly contained inside the component where it began.
A topology map shows how services, infrastructure and other resources depend on each other. Add causal reasoning and the RCA system can start asking whether the sequence of failures follows those real relationships, instead of simply grouping abnormalities because they happened close together.
AWS DevOps Agent, for instance, builds an application topology that maps resources and their relationships for use during investigations. XiHe goes further by representing the suspected chain explicitly as a causal graph that operators can inspect.
Neither approach guarantees the diagnosis is correct. What they do is make the reasoning easier to test. An operator can see whether the supposed cause is actually upstream of the affected service and whether the resulting failure path makes sense inside the architecture they operate every day.
What doesn't the system know?
This may be the most useful question of the four, because operational data is rarely complete. A team may have excellent application telemetry but limited visibility into one external dependency. Logs might be unavailable. A topology map may be stale. A new service may not yet be instrumented properly.
A trustworthy RCA system needs some way of recognising those limits. Confidence shouldn't simply describe how convincing the model finds its own answer. It should reflect whether enough supporting information exists to justify the conclusion being made.
This becomes especially important as infrastructure becomes more interconnected. A highly confident diagnosis based on three well-instrumented services can still be wrong if the actual failure began in a fourth dependency the system couldn't see.
Operational trust therefore depends partly on what the RCA platform does with gaps.
- Does it identify them?
- Does its confidence change?
- Can it narrow the likely fault domain without pretending it has proved the exact cause?
Those behaviours tell teams considerably more than a high accuracy benchmark by itself.
How will the conclusion be tested?
Finally, a diagnosis should create something that can be tested. If the suspected cause is real, correcting it should produce an observable change in the systems affected. That gives infrastructure teams a way to verify the reasoning rather than simply accepting it.
This is also where diagnosis starts connecting naturally to remediation. A good recommendation shouldn't only tell an engineer what to change. It should explain why the action addresses the identified cause and what result would indicate that the hypothesis was correct.
Once RCA is treated this way, the process starts looking less like a machine producing an answer and more like an investigation producing a testable conclusion. That's a much stronger foundation for deciding what the system should be allowed to do next.
Knowing When Not To Diagnose Is Part Of Reliable RCA
Most RCA benchmarks understandably focus on finding the correct root cause. But there's another behaviour worth measuring: what happens when the available evidence isn't strong enough to establish one?
For an engineer, “I don't know yet” is a perfectly valid outcome. It might mean collecting another log, checking a dependency the monitoring stack can't see or bringing someone with deeper knowledge into the investigation. The important thing is recognising that the evidence doesn't justify certainty yet.
Automated systems need the same option. XiHe's architecture is useful here because its evidence-driven process can help constrain the likely fault area when information is incomplete rather than requiring every investigation to end with an unsupported root-cause claim.
There are good reasons to take that behaviour seriously. Datadog found while developing its Bits Investigation agent that a change improving one type of investigation could quietly make others worse. Nothing crashed and conventional tests didn't fail. The agent simply began making poorer decisions in scenarios the development team hadn't anticipated.
Datadog eventually built a replayable evaluation platform so it could test agent behaviour across realistic production incidents. That experience is a useful reminder that AI investigation quality isn't static. Models, prompts, context and tooling change, and improvements in one area don't necessarily improve the whole system.
So reliable RCA includes calibrated uncertainty. Teams need systems that can distinguish between enough evidence to diagnose, enough evidence to narrow the investigation and not enough evidence to proceed safely. Without that distinction, confidence becomes decoration rather than an operational control.
More Evidence Should Be Required As Operational Authority Increases
Not every remediation decision carries the same risk. Restarting a stateless service in a test environment is very different from changing production routing, failing over a database or modifying infrastructure supporting a critical transaction. Treating them as equivalent would make automation either dangerously permissive or unnecessarily restrictive.
A more useful approach is to make the evidence threshold rise with operational consequence. The greater the potential blast radius, the harder an action is to reverse, and the less certain the diagnosis, the stronger the justification should be before an automated system proceeds.
That doesn't automatically mean adding a person to every decision. Low-risk, well-understood and easily reversible actions may be reasonable candidates for autonomous remediation when the supporting evidence is strong and the outcome can be verified immediately.
Higher-impact changes deserve a different standard. The same automated RCA can still do most of the investigative work, but the system may stop at a recommendation while an operator reviews the causal path, proposed action, expected impact and rollback option.
Organisations are already wrestling with that boundary. Dynatrace's 2026 survey of 919 leaders responsible for agentic AI found that 69 per cent of agentic AI decisions are currently verified by humans. The research also found that IT operations and DevOps were using agentic AI more widely than any other function measured.
The interesting question isn't therefore whether humans or machines should control remediation. It's what quality of evidence is sufficient for this particular action, in this particular environment, with this particular consequence if the diagnosis is wrong.
Remediation Isn't Complete Until The Fix Is Verified
There's one final trap here. An automated system can execute the recommended action successfully without fixing the incident. The command may run exactly as intended. The service may restart. The configuration may change. None of that proves the diagnosis was right.
The real test comes afterwards.
- Did the symptoms disappear?
- Did the affected service recover?
- Did downstream dependencies return to normal?
- Did the change create a new problem somewhere else?
- And, perhaps most importantly, did the supposedly resolved failure return five minutes later?
AWS's current DevOps Agent documentation explicitly includes validating success and reverting changes where necessary as part of mitigation. Splunk's remediation workflow similarly has operators work through hypotheses, execute suggested steps and return the resulting output so the plan can determine what happens next.
That closes an important loop. Automated remediation should produce new evidence, which can either confirm the original diagnosis or show that the investigation needs to continue.
Seen this way, root-cause analysis isn't a straight line from alert to answer to fix. It's an evidence cycle. Observe what happened, build a hypothesis, test it, act where justified, and then confirm whether reality behaved the way the diagnosis predicted.
What Infrastructure Teams Should Ask Before Trusting Automated RCA
For infrastructure teams assessing their own RCA capabilities or evaluating an AIOps platform, the most useful questions are less about how impressive the AI appears and more about what can be verified around it.
- Can we inspect the evidence behind the diagnosis? Operators should be able to trace conclusions back to relevant telemetry, events and changes rather than accepting an isolated generated answer.
- Can the system demonstrate the causal path? Correlation should be supported by topology, dependencies or other evidence showing how the suspected failure produced the observed impact.
- Does it identify missing information and uncertainty? The platform needs a meaningful response when telemetry is incomplete or several explanations remain possible.
- Can operators test alternative hypotheses? A diagnosis becomes more trustworthy when competing causes can be examined rather than silently discarded.
- Does the evidence threshold change with the proposed action? Higher-risk or difficult-to-reverse remediation should require stronger justification than routine, low-impact automation.
- Can the action be reversed safely? Rollback needs to be part of the decision before remediation begins, not something teams improvise after it goes wrong.
- How does the system verify the outcome? Successful execution isn't enough. Teams need evidence that the underlying incident was actually resolved.
- Can the investigation be reconstructed afterwards? An audit trail should show what information the system considered, what it concluded, what was approved and what changed.
None of these questions requires an RCA system to be perfect. Infrastructure teams have never had perfect information during every incident, and human diagnoses aren't infallible either. The goal is something more practical: making sure automation doesn't remove the ability to question how a conclusion was reached.
That becomes more valuable as incident response moves from AI-assisted investigation towards autonomous IT operations. The technology may do increasingly more of the work, but the organisation still needs a defensible way to decide when the work is good enough to trust.
Final Thoughts: Automated RCA Needs To Show Its Work
The appeal of automated root cause analysis is easy to understand. Nobody wants an experienced engineer spending half a day moving between dashboards and log files if a system can identify the same problem in minutes. Faster diagnosis means shorter incidents, less operational toil and more time spent improving infrastructure instead of firefighting.
But speed changes the equation once the diagnosis starts influencing what happens next. An answer that helps an engineer decide where to look doesn't need the same level of proof as one being used to justify an autonomous change to production infrastructure.
That's where the next stage of AIOps may be taking shape. The strongest systems aren't simply getting better at generating diagnoses. They're being designed around evidence, causal relationships, uncertainty, verification and increasingly explicit controls over what happens when a conclusion leaves the investigation and becomes an action.
For infrastructure teams, that creates a fairly simple standard to carry forward. Automated RCA doesn't need to remove judgement from incident response. It needs to give engineers enough evidence to exercise that judgement well, while allowing routine decisions to become safer to automate where the consequences justify it.
The systems that earn greater operational authority will therefore need to do more than get the answer right most of the time. They'll need to make their reasoning inspectable, recognise when the evidence runs out and prove that the action they recommended actually worked.
As infrastructure automation continues moving closer to autonomous operations, EM360Tech will keep following how AIOps, observability and operational platforms are changing the decisions infrastructure teams can automate, and the evidence they'll need before handing those decisions over.
Comments ( 0 )