How to write a root cause analysis report for an IT incident
The sections an evidence-linked RCA needs, and how to write them
A root cause analysis report for an IT incident should let a reader who was not there understand what broke, why, how it was found, and what stops it recurring, and check every claim against the evidence. This guide lists the sections an evidence-linked report needs, then walks through the writing process from timeline to sign-off.
The test of a good RCA report: someone outside the team could verify it. If a claim cannot be traced to a log line, a trace, a metric or a change record, it is a hypothesis and should be labelled as one.
What sections should a root cause analysis report include?
These are the sections of the root cause report Onepane produces, and they map closely to what customers, auditors and problem-review boards expect. See the full artifact at /artifacts/root-cause-report.
Incident identity and severity
Incident ID, severity, services affected, start and end times, who led the response. Enough for a reader to find the incident in the ITSM record.
Impact statement
Which customers or business functions were affected, for how long, and how badly. Stated in the recipient's terms: failed transactions, delayed jobs, unavailable regions.
Timeline
Detection, escalation, key investigation steps, cause identification, mitigation, resolution, each with a timestamp and a source. The timeline is where most reports are vague.
Causal chain: trigger, propagation, failure
What started it, how it travelled through dependencies, and what the customer saw. One root cause, stated as a specific verifiable fact.
Contributing factors
Conditions that made it more likely, longer or worse, held distinct from the root cause, each with its own corrective action.
Evidence index
Every claim in the report linked to the telemetry, log line, trace or change record that supports it, with timestamp and source. This is what makes it audit-grade.
Corrective actions
Immediate fix and preventive measures, each with a named owner and a date. Vague actions such as improve monitoring do not count.
Confidence statement
How sure you are, what alternatives were considered, and what evidence was missing. If the cause could not be determined, say so and say what would decide it.
How do you write the report?
Write in this order. It is not the order the sections appear in, but it is the order in which the facts become available and defensible.
- 1
Build the timeline from sources, not memory
Pull alert timestamps, chat transcripts, deployment logs, change records and dashboards into one ordered list before writing a sentence of narrative. Every entry gets a source. Memory of an incident is reliably wrong about order and duration.
- 2
Assemble the change timeline for the window before the first symptom
Deployments, config changes, IaC applies, feature flags, cloud-provider events, scaling actions. Most incidents follow a change; the change list is the first hypothesis set.
- 3
Trace the causal chain from failure back to trigger
Start at the customer-visible symptom and walk back through the dependency graph, confirming each hop with evidence. Stop when you reach a condition that, had it been absent, would have prevented the incident.
- 4
Separate the root cause from the contributing factors
Write the root cause as one specific sentence. Then list the conditions that made it worse. If you find yourself writing several root causes, you probably have one cause and several factors, or you have not finished.
- 5
Write the evidence index as you go
Each claim in the timeline and causal chain gets a numbered evidence entry: source, query or link, timestamp, what it shows. Doing this at the end guarantees gaps.
- 6
Draft the impact statement in the recipient's terms
Not which pods restarted, but which customer operations failed, for how long, and how many. If you are also producing a customer-facing version, this section is where it starts.
- 7
Agree corrective actions with the owners before publishing
An action nobody has accepted is a wish. Name the owner, set the date, and put the action into the tracking system before the report goes out.
- 8
State confidence honestly and get it signed
Say what you are sure of, what you are not, and what would settle it. Then have the incident lead or problem manager review and sign. An unsigned RCA is a draft.
How does a customer-facing RCA differ from the internal report?
The customer-facing version is derived from the internal report, not written separately. It keeps the impact statement, a plain-language cause, the timeline at the level of customer-visible events, and the corrective actions. It removes internal hostnames, employee names, raw log excerpts, and architectural detail that is not needed to understand the cause. It should survive the recipient's vendor-risk review without generating follow-up questions, and it is usually owed within a contractual window, so it should be produced from the same evidence at the same time.
Onepane produces the report, with the evidence index attached.
Onepane's Root Cause Report follows exactly this structure, generated inside your VPC from your own telemetry, with every claim linked to evidence and engineers signing off before delivery. The customer-facing RCA and executive summary are produced from the same investigation. See /artifacts/root-cause-report.
The bottom line: A root cause analysis report is complete when a stranger could verify it: sourced timeline, one specific root cause with the causal chain, contributing factors held apart, an evidence index, owned corrective actions and an honest confidence statement, signed by the person accountable.
Onepane delivers the root cause report, evidence index and customer-facing version from one evidence-linked investigation inside your VPC.