Atlassian has outlined a new approach to automating root cause analysis for large-scale cloud-native incidents, using correlation across metrics, logs, distributed traces, and service topology to generate ranked hypotheses about where failures originate and how they propagate. Published through the Cloud Native Computing Foundation, the work addresses one of the most time-consuming parts of incident response: the manual process of switching between dashboards and tools to connect individual telemetry signals into a coherent explanation.
The system treats root cause analysis fundamentally as a multi-signal correlation problem across signal type, time, and topology. Rather than asking an on-call engineer to manually identify an anomaly, search logs and traces, and then reconstruct the dependency chain, the platform independently detects anomalies across each signal before aligning them on a common timeline and tracing them through a service dependency graph. The result is a ranked set of hypotheses identifying a likely fault origin, propagation path, and supporting evidence.
Atlassian's approach begins by reducing the search space. Rather than analysing every service across a large production environment, the system uses OpenTelemetry-derived service maps to identify the subset of services involved in the affected user journey. The dependency graph is built from actual production traffic, using parent-child relationships between spans to show how services communicate in practice rather than relying on static architectural documentation.
The system applies different detection methods to metrics, traces, and logs. Metrics are checked for changes in rates, errors, and duration, while traces are analysed for exceptions, latency, and structural changes. Logs are grouped to identify new or unusual error patterns. These findings are then converted into a common anomaly format for correlation.
Anomalies occurring close together in time can then be grouped into a potential failure sequence. For example, a database issue followed by application timeouts and frontend errors may be treated as part of the same incident. Sequence fingerprinting is used to reduce duplicate versions of recurring failure patterns.
Time alone cannot establish causation, however. The system also considers service dependencies and the order in which anomalies appeared, tracing upstream from affected services to identify possible sources of the failure. This produces a ranked hypothesis of how the incident may have originated and propagated.
The output summarises the suspected cause, affected services, and supporting telemetry rather than simply presenting a list of anomalies. Engineers can then review the evidence and validate the diagnosis before taking action.
As cloud-native systems become more distributed, the challenge is increasingly not collecting telemetry, but correlating it quickly enough to support effective incident response.
That problem is amplified by tool fragmentation. A 2026 CNCF community survey cited that many organisations continue to operate multiple observability platforms simultaneously, requiring engineers to bridge metrics, logs, and traces across different tools manually. Atlassian's architecture attempts to replace that human correlation effort with a shared anomaly model and dependency-aware reasoning engine.
Commercial observability platforms are pursuing similar goals. Grafana Cloud is building a knowledge-graph approach that correlates telemetry and infrastructure relationships to surface likely causes, while Dynatrace correlates events from multiple sources alongside logs, metrics, and traces to identify problems and their likely impact. The difference in Atlassian's model is its detailed focus on a modular, signal-normalised pipeline in which individual anomaly detectors can evolve independently while the same correlation layer reasons over the resulting evidence.
Atlassian says they are now exploring the next step: using LLM-based orchestration to make investigations iterative. Instead of running the RCA engine once and presenting a fixed answer, an agent could request additional telemetry, test competing hypotheses, and adapt its investigation based on the evidence available. Atlassian notes, however, that such systems will require controls around rate limits, execution environments, and evidence provenance.
As cloud-native architectures continue to add services, dependencies, and telemetry, the ability to automatically transform thousands of disconnected signals into a small number of evidence-backed hypotheses may become one of the most valuable capabilities in modern reliability engineering. The challenge will be ensuring that those systems remain explainable enough for engineers to trust, and grounded enough in real telemetry that automation accelerates understanding rather than simply generating a more convincing guess.