Atlassian believes that root cause analysis for incidents in microservices environments can no longer rely on manual review alone. When hundreds of interconnected services operate across multiple regions, a single failure produces a large volume of metrics, logs, and traces, while the on-call engineer typically has to navigate separate dashboards and build a mental hypothesis about the source of the problem and its propagation path.
In a post on the CNCF blog, Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee, and Lavender Neesham from Atlassian explain an automated root cause analysis system designed to automate hypothesis generation, allowing the response team to move more quickly to verification and remediation instead of manually reassembling evidence.
Turning Root Cause Analysis into a Multi-Signal Correlation Problem
The design links three layers of evidence: signal type, time, and service topology. The signals include metrics, logs, and traces, while temporal alignment identifies events that may be related, and the service dependency graph helps distinguish the service that initiated the failure from those affected by it later.
The process begins by narrowing the search scope through a service map derived from OpenTelemetry. Rather than analyzing every service on the platform, the system identifies the services on the path of the degraded user experience, creating a scope that typically includes dozens of services instead of hundreds. The map reflects actual communications extracted from parent-child relationships between spans in production traffic, not the structure assumed in documentation.
From Monitoring Data to Ranked Hypotheses
After the scope is defined, independent modules detect anomalies in each signal type. For metrics, Atlassian monitors RED indicators—request rate, error rate, and response duration—using statistical methods such as median absolute deviation and percentile ranges. Each anomaly produces a severity value, the observed value, and the baseline from which it deviated.
Distributed traces are examined for unexpected exceptions, new error-propagation patterns, and increases in latency on specific spans. Logs use embedding-based clustering techniques to group semantically similar entries, then highlight new or rare error clusters compared with the service’s usual distribution.
All detectors convert their results into events with a unified schema that includes a timestamp, service name, signal type, severity score, and details. This layer allows the correlation engine to analyze events without depending on the method each detector used to identify the condition. It also allows new detectors to be added or one statistical model to be replaced with a machine-learning-based model without rebuilding the entire system.
Time and Dependency Graphs for Determining the Direction of Failure
The engine groups nearby events within a configurable time window, usually plus or minus five minutes. Each group receives a temporal-cohesion score; the closer the events are, the greater the likelihood that they are related. To prevent the same hypothesis from being repeated dozens of times, the system uses fingerprints for service sequences and merges repeated failure chains into one group while counting the number of replays. Thus, a failure pattern that occurred 47 times within five minutes can be described instead of creating 47 identical hypotheses.
The system then identifies the most affected node, or what it calls the downstream node, and moves backward through the dependency graph to look for anomalous services that preceded it in time. If service A calls service B, and a problem appears in B before a problem appears in A, B becomes a stronger candidate for the source of the failure, while the problem in A is treated as a subsequent effect. The final assessment combines temporal cohesion with propagation-path scoring to rank the hypotheses.
The result is not limited to a list of services and confidence scores. Each hypothesis includes the suspected service, the propagation path, evidence at each node—such as metrics that exceeded their thresholds or trace IDs associated with the failure—as well as a human-readable narrative explaining the sequence of events and why a particular source was favored.
Why Does This Methodology Matter to Operations Teams?
The practical value here is not replacing the response engineer, but reducing the time required to reach a testable hypothesis. Atlassian connects the root cause analysis engine to a broader incident response platform that includes detecting the impact of the failure on users, identifying the responsible team, and an incident assistant that can suggest actions such as rolling back a release or disabling a feature flag based on the available evidence. The platform also records whether engineers accepted, rejected, or modified the hypothesis in order to improve the weights over time.
The experience shows that starting with simple, interpretable methods may be more appropriate than building complex machine-learning models for every signal. Methods such as median absolute deviation and percentile ranges were sufficient to detect many metric anomalies, while machine-learning techniques were used for log clustering and trace-structure analysis, where statistical methods are less suitable.
However, the methodology does not eliminate limitations. The quality of the hypotheses depends on the consistency of monitoring data, the accuracy of the service dependency graph, and the detectors’ ability to distinguish real failures from noise. A confidence score is also not final proof of causality; therefore, Atlassian emphasizes the importance of showing the source of each piece of evidence and the narrative connecting it to the result. The company is also exploring the future use of a language-model-based format that could request additional data and modify hypotheses, subject to rate limits, isolated execution, and a clear record of the origin of the evidence.
Editorial reading from certi.news: The actual change in this approach is moving incident analysis from manual comparison between separate tools to a unified process that integrates signal, time, and topology. Its operational success will depend on interpretability, data quality, and feedback loops, not on the ranking algorithm alone. For this reason, modularity, deduplication, and evidence documentation appear to be principles that can be applied immediately more readily than the promise of fully automating root cause analysis.