Restarting a crashed service ends the incident; root cause analysis asks why it crashed. In software, the visible symptom is often several steps away from the cause. A checkout page times out because the connection pool is exhausted, the pool is exhausted because a query got slow, and the query got slow because a new release dropped an index. RCA follows that chain back to something you can fix.
Common RCA methods
- 5 Whys. Ask "why?" repeatedly, usually about five times, until you reach a cause you can act on. Simple and fast, but it can stop at one cause when there are several.
- Fishbone (Ishikawa) diagram. Brainstorm possible causes by category, such as code, infrastructure, dependencies, process and people.
- Fault tree analysis. Work backwards from the failure through the combinations of events that could produce it.
- Change analysis. List everything that changed just before the problem: deploys, configuration, traffic, dependencies, certificates. Recent changes are among the most common causes of incidents.
- Timeline reconstruction. Put alerts, deploys, logs and actions in order to see what happened first.
RCA for software incidents, step by step
- Define the problem precisely: what failed, where, when it started and who was affected.
- Build a timeline from metrics, traces, logs and change events.
- Find the contributing causes. There is usually more than one.
- Verify each cause with data or by reproducing the problem, instead of settling on the first plausible story.
- Fix and add guardrails: a test, an alert, a limit or a safer rollout process.
- Share it in a blameless postmortem, so other teams learn from it too.
Root cause or contributing factors?
Complex systems rarely fail for a single reason. A bad query, a missing alert and a busy release day can all be needed for an outage. Many teams talk about "contributing factors" instead of one root cause, so the analysis doesn't stop at the first answer or turn into blaming the person who pushed the change.
Root cause analysis with Atatus
APM traces show where a slow or failing request spent its time, down to the database query or external call, and deployment tracking shows whether a release changed performance. Log management links log lines to their traces. AI SRE groups related alerts into one Problem, marks which issues are causes and which are symptoms, and suggests a probable root cause with the evidence, alternatives and an action plan. For a hands-on walkthrough, read root cause analysis with observability.