Root-cause an incident

Separate the trigger from the root cause, with every claim tied to a line in the timeline — the discipline that stops a plausible story from replacing the real one.

When to use it

Working through an incident or a failure where the tempting explanation and the real one may differ, and you want the reasoning tied to evidence.

What it prevents

The plausible story that replaces the real cause. Models are fluent at narrative and will confidently name a root cause that fits the vibe of the timeline. Forcing the trigger-versus-cause distinction and a timeline citation for every claim is what keeps the analysis anchored to what actually happened.

The prompt

Analyse the incident timeline below and identify the most likely root cause.

### Output format
Three sections — Timeline (the events ordered by time), Root cause (one paragraph), and Contributing factors (a bulleted list).

### Requirements
- Distinguish the root cause from the trigger: the trigger is what fired, the root cause is why it could.
- Support each claim with a specific line from the timeline.
- Where two causes both fit the evidence, say so rather than picking one.

### Timeline
"""
09:02 deploy of v2.4. 09:05 error rate rises. 09:20 rollback. 09:22 recovery. No database changes in the window.
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Avoids dangling references — why this matters
• Separates data from instructions — why this matters
• Avoids over-aggressive phrasing — why this matters

How to adapt this one

Paste your real timeline and keep the two disciplines: separate the trigger (what fired) from the root cause (why it could), and cite a specific line for each claim. The “where two causes both fit, say so” clause is the honesty valve — real incidents are often underdetermined by the evidence, and a model forced to pick one will manufacture certainty you do not have.

The mistake this prompt avoids

Confusing the trigger with the cause. “The deploy caused the outage” names what fired, not why the system was fragile enough to break — and if you fix only the trigger, the next deploy breaks it again. Make the model distinguish them, because the durable fix lives at the root, and the trigger is just the thing that happened to expose it.

A variation

Writing this up for a blameless postmortem rather than your own understanding? Ask for the same evidence-tied analysis plus a short “what would have caught this earlier” section — the missing alert, the absent test, the review that did not happen. A postmortem's value is not naming the cause but naming the gap in the system that let it reach production unnoticed.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.