Help me run an evidence-based root cause analysis for the incident below. Do not choose a root cause simply because it is the first failure observed. Separate verified facts, hypotheses, contributing conditions, and actions. Incident and impact: [INCIDENT DESCRIPTION] Timeline and evidence: [TIMELINE AND EVIDENCE] System or process context: [PROCESS CONTEXT] Known controls and prior incidents: [CONTROLS AND HISTORY] Action owners and constraints: [OWNERS AND CONSTRAINTS] Produce a report with these sections: 1. Incident statement: what happened, when, who or what was affected, scope, and measurable impact. 2. Fact timeline in chronological order. Mark unknown timestamps and conflicting accounts. 3. Evidence inventory, separating logs, records, observations, and assumptions. 4. Causal analysis using a cause-and-effect chain. Identify the triggering event, direct cause, root cause candidates, and contributing factors across people, process, technology, inputs, and environment. Use “5 Whys” only where each answer is supported by evidence. 5. Root-cause conclusion: state the best-supported cause or say evidence is insufficient. Explain why plausible alternatives were rejected or remain open. 6. Corrective and preventive action table with action, owner from [OWNERS AND CONSTRAINTS], due date or proposed timeframe, success measure, and verification method. Include containment actions separately from systemic prevention. 7. Risks, assumptions, and data still needed. Do not assign blame to individuals when process or system evidence is incomplete. Do not invent dates, owners, log entries, or compliance findings. Before answering, check that each conclusion traces to evidence and that every action addresses a stated causal factor rather than only the symptom. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [INCIDENT DESCRIPTION] | Describe what failed, its impact, scope, and when it was detected. | On 14 May, 186 subscription renewals were charged twice after a billing release; 42 customers contacted support within 24 hours. |
| [TIMELINE AND EVIDENCE] | Paste timestamps, logs, tickets, screenshots, observations, and relevant quotes from witnesses. | 09:02 deployment started; 09:10 webhook retry setting changed; 10:00 renewal job ran; payment logs show duplicate idempotency keys missing for 186 orders. |
| [PROCESS CONTEXT] | Explain the normal workflow, systems, handoffs, and expected controls. | Engineering deploys billing changes through review, staging test, release checklist, and Datadog payment alerts. |
| [CONTROLS AND HISTORY] | List existing safeguards, monitoring, procedures, audits, and similar prior incidents. | Idempotency keys are required by the payment integration guide; no automated test covers webhook retries; a smaller duplicate-charge incident occurred in January. |
| [OWNERS AND CONSTRAINTS] | List available action owners, decision rights, deadlines, budgets, and operational constraints. | Maya owns billing engineering, Theo owns support operations, finance can issue refunds within two business days; no freeze on other releases. |
How to use
- Collect evidence before prompting, including timestamps, system changes, and the normal process that should have prevented the incident.
- Ask the model to mark gaps rather than filling them with a plausible narrative.
- Confirm action owners and due dates with the people named before circulating the report.
- Follow up with: “Convert the action table into a 30-day review agenda with proof each action is complete.”
Variations
Five whys session
Use this when you need a facilitated, evidence-led team discussion.
Facilitate a 5 Whys session for [PROBLEM]. Evidence we have: [EVIDENCE]. Participants: [PARTICIPANTS]. Create a 45-minute agenda, then draft one evidence-based “why” chain with alternatives where evidence is weak. For each why, label fact, inference, or unknown. End with questions to test the leading cause and candidate prevention actions. Do not blame individuals or treat a hypothesis as proven. Ask up to 3 questions only if required inputs are missing.
Corrective action plan
Use this after the cause is known and execution is the priority.
Turn this validated root-cause finding into a corrective action plan: [ROOT CAUSE FINDING]. Constraints and owners: [CONSTRAINTS]. Required standard or policy: [REQUIREMENTS]. Produce a table with containment, correction, prevention, owner, due date, dependency, success metric, evidence of completion, and review date. Add a short risk assessment for actions delayed or declined. Do not create commitments or dates not supplied; label proposed dates. Ask up to 3 questions only if required inputs are missing.
Incident postmortem
Use this when writing a blameless operational retrospective.
Write a blameless incident postmortem from [INCIDENT NOTES] for [AUDIENCE]. Include impact, detection, timeline, contributing factors, root-cause status, what went well, what did not, and action items with [OWNERS]. Use factual language and distinguish verified events from open questions. Exclude personal criticism and customer-identifying details. Finish with a two-sentence executive summary. Check that actions have owners and success measures. Ask up to 3 questions only if required inputs are missing.
Tips
- Start with a precise incident statement that includes scope and impact; “the system failed” cannot be investigated or measured.
- Keep a time-ordered record of events separate from explanations, because a tidy narrative can hide missing evidence.
- Containment stops immediate harm, while corrective actions remove the present defect and preventive actions change the conditions that allowed it.
- Close actions with proof, such as a test result, audit sample, or metric threshold, rather than marking them complete after implementation.
FAQ
Is 5 Whys enough for a root cause analysis?
It can reveal a useful chain for a simple failure, but it can oversimplify incidents with multiple interacting causes. Pair it with evidence and contributing-factor analysis.
Can AI determine the root cause from a short description?
It can organize hypotheses, but a short description rarely proves causality. Give it logs, timestamps, workflow context, and conflicting evidence.
Should a root cause analysis name people?
Name accountable owners for actions. Avoid treating an individual's mistake as the root cause until the surrounding process, training, tools, workload, and controls have been examined.