The operations leader's guide to root cause analysis.

The explicit decision by an AI or human investigator to report that the root cause cannot be determined from available evidence, stating what is missing, instead of returning a best guess. Abstention is a first-class output in trustworthy AI root cause analysis, and abstention rate is a service metric published alongside accuracy and time to RCA.

Corrective and preventive action. A CAPA record ties each root cause to the action that fixes it and the action that stops it recurring, with an owner, a due date and closure evidence. Borrowed from quality management, CAPA is the artifact auditors ask for in healthcare and financial services when they want to know an outage was actually followed up.

The ordered sequence of events linking the root cause to the customer-visible failure, with each step supported by evidence. A complete causal chain answers the question at every hop: this happened, which caused that. Gaps in the chain are where confidence drops, and an honest RCA marks them rather than filling them with assumption.

A structured classification of an incident or problem's root cause, chosen from a controlled list such as change-induced, capacity, dependency failure, configuration or defect. Cause codes make root causes reportable across many incidents. They lose value when the list is too long, when engineers default to Other, or when the code is not linked to evidence.

Establishing which deployment, configuration change, infrastructure-as-code apply, feature flag or cloud-provider event is implicated in an incident, with the diff and its approval record. Change attribution is a statement of what changed, held distinct from who approved it. It is the single most useful step in most investigations because most outages follow a change.

Configuration management database: the ITSM record of configuration items, their attributes and their relationships. A CMDB is meant to answer what depends on what and who owns it. In practice most are stale because they are updated by hand, which is why RCA methods that require an accurate CMDB stall and why observed topology is used instead.

The section of an RCA that says how sure the investigator is of the stated cause, which alternative hypotheses were considered, and what evidence was missing or ambiguous. Written in plain terms rather than as a bare percentage. The confidence statement is what lets a reviewer decide how much weight to put on the conclusion before signing.

The section of a root cause report that links every factual claim to the telemetry, log line, trace, ticket or change record supporting it, with a timestamp and source. The evidence index is what makes an RCA verifiable rather than persuasive, and it is the part an auditor, a customer or a sceptical engineer checks first.

A service in which a provider is accountable for an outcome against an SLA, rather than supplying software for the customer to operate. In root cause analysis this means the RCA arrives, on time, signed off, and someone outside the customer's team is answerable when it does not. Managed services are bought from labour or services budgets, not tooling budgets.

Mean time to detect: the average time between a fault starting and someone or something noticing it. MTTD is a monitoring and alerting metric. A long MTTD lengthens every downstream measure, and it often shows up in RCAs as a contributing factor when the fault ran unnoticed while customers were already affected.

Mean time to identify: the average time from detection of an incident to identification of its cause. MTTI sits between MTTD and MTTR and is the metric most directly improved by better root cause capability. Because some vendors use MTTI to mean time to investigate, always state the definition when you report it.

The structured review held after an incident is resolved to establish the timeline, confirm the cause, agree corrective actions and capture lessons. A post-incident review consumes the RCA and the evidence pack; it should not be where the investigation starts. In many organisations it is the same meeting as a postmortem or a problem review.

A contractual commitment to deliver a written root cause analysis within a stated period after a qualifying incident, commonly a few business days after a Sev1, sometimes with a shorter preliminary RCA and a longer final one. An RCA SLA is usually attached to service credits and is the clause that turns RCA from an internal task into a deliverable.

An evaluation method in which a provider is given a customer's historical Sev1 tickets, typically the last 90 days, and produces the root cause and RCA document for each without seeing the human-written result. Output is scored against what the human actually found, on accuracy and time to cause. It replaces the demo and sets the SLA the provider can safely commit to.

The formal post-incident document a carrier, network provider or MSP sends a customer explaining why service was unavailable, for how long, how it was restored and what prevents recurrence. An RFO is a customer-facing RCA under telecom and managed-service vocabulary, and it is normally a contractual deliverable tied to SLA credits.

A contractual remedy, usually a percentage of monthly fees, owed to a customer when a provider misses an SLA. Availability credits are familiar; RCA delivery credits are increasingly common in enterprise MSAs, so a late RCA has a direct cost as well as a relationship cost. Credits are the mechanism that makes a managed RCA service accountable.

A maintained record of which team owns each production service, its dependencies and how to reach the owner, current enough to be trusted during an incident. Built from deployment metadata, tags, on-call rotations and observed traffic rather than from hand-edited CMDB entries. Answers the question that stalls large-estate investigations: who owns the thing that is red.

The degree to which a service emits enough logs, metrics, traces and change events for an investigator to reach a confident cause. Low coverage caps RCA accuracy regardless of method. A telemetry coverage or RCA readiness assessment lists the blind spots per service before an SLA is agreed, and it is usually the first useful artifact of an evaluation.

The elapsed time from closure of a Sev1 incident to delivery of a signed, accepted root cause analysis. Time to RCA measures the written deliverable, which is what an RCA SLA actually tests. It is distinct from MTTI, which ends at identification. Track it per incident and per severity against the committed window.

The graph of services, infrastructure and their dependencies as they actually run: which service calls which, what it runs on, what it reads from. Topology is what lets an investigation follow a fault from the first symptom back to the change that caused it. Observed topology, derived from traces, traffic and deployment metadata, is more reliable than a documented one.