Chain-of-Thought Root Cause Analysis Prompt Template

This prompt is designed for SREs, on-call engineers, and technical leads who are actively investigating a production incident and have already gathered initial telemetry. The primary job-to-be-done is to transform a collection of symptoms, logs, metrics, and timeline events into a structured, auditable causal chain. It forces the model to reason step-by-step from an observed symptom to the most likely root cause, requiring explicit evidence for each causal link. This is not a first-responder alerting tool or a replacement for automated runbook execution. Use it when the incident is complex enough that a linear narrative will help the team align on what is known, what is assumed, and what still needs to be proved.

The ideal user has already triaged the immediate blast radius and collected relevant data: error logs, latency spikes, deployment markers, infrastructure changes, and any correlated alerts. The prompt works best when you provide a structured [INCIDENT_TIMELINE] and a set of [OBSERVED_SYMPTOMS] as input. It is particularly effective for incidents involving multiple services, asynchronous failures, or subtle interactions where a single obvious cause does not exist. Do not use this prompt when the incident is still unfolding and you lack any concrete data, or when the resolution requires immediate automated rollback rather than analysis. It is also a poor fit for simple, well-understood failure modes that a runbook already covers.

The output is a causal chain that separates verified facts from assumptions, making it suitable for inclusion in postmortems or handoff documents. However, the model cannot access your live systems, so every claim it makes must be validated against real data before action is taken. Treat the generated analysis as a structured hypothesis, not a confirmed diagnosis. After receiving the output, your next step should be to review each 'Assumption' flag, gather the missing evidence, and update the chain. Avoid the temptation to copy-paste the analysis into an incident retrospective without human review, especially for customer-impacting or security-sensitive incidents where an incorrect root cause can misdirect remediation efforts.

This section provides the core prompt template for the Chain-of-Thought Root Cause Analysis workflow. It is designed to be pasted directly into an AI harness and forces the model to reason step-by-step from an observed symptom to the most likely root cause, explicitly stating the evidence required at each link in the causal chain. The template is structured to prevent the most common failure mode in incident analysis: jumping to a conclusion based on a single, unverified hypothesis.

textCopy
You are an SRE investigator performing a root cause analysis for a production incident. Your goal is to construct a causal chain from the initial symptom to the most probable root cause, not to generate a list of unrelated possibilities.

**Incident Summary:**
[Symptom]: [Describe the observed failure, e.g., 'HTTP 500 errors on the checkout service at 14:03 UTC']
[Alert Context]: [Paste the alert payload, dashboard link, or initial triage notes]
[Timeline of Events]: [Provide a timestamped list of deployments, config changes, or metric anomalies]
[Available Evidence]: [Paste relevant logs, graphs, error messages, or runbook links]

**Instructions:**
1.  **State the Initial Symptom:** Restate the observed failure in precise terms.
2.  **Generate Hypotheses:** List 2-4 distinct, plausible causal chains that could explain the symptom. For each hypothesis, state the key assumption that must be true.
3.  **Chain-of-Thought Analysis:** For the most likely hypothesis, construct a step-by-step causal chain from the symptom back to the root cause. At each step, you must:
    - State the causal link (e.g., 'The checkout service returned 500 errors because it could not connect to the payment gateway.').
    - List the **Required Evidence** to confirm this link (e.g., 'Checkout service connection logs showing timeout to payment-gateway.internal:443').
    - If the evidence is missing, flag it as an **[UNVERIFIED ASSUMPTION]**.
4.  **Identify the Probable Root Cause:** Conclude with the single most probable root cause based on the completed chain.
5.  **Evidence Gap Analysis:** List all [UNVERIFIED ASSUMPTION] flags from your chain. These are the highest-priority items for immediate investigation.

**Constraints:**
- Do not propose a fix until the root cause is identified.
- Distinguish between correlation and causation. A timeline match is not proof.
- If two hypotheses are equally likely, state that you are at a decision point and cannot proceed without more evidence.
- Do not fabricate evidence. If you are inferring a state, mark it as an assumption.

To adapt this template, replace the square-bracket placeholders with incident-specific data. The quality of the output is directly proportional to the quality of the [Available Evidence]. If you provide only a vague symptom, the model will generate a shallow analysis full of unverified assumptions. For high-severity incidents, the output of this prompt should be treated as a structured starting point for a human investigation, not a final verdict. The [UNVERIFIED ASSUMPTION] flags are the most critical output; they define the immediate next steps for the on-call engineer.

This prompt is designed to be integrated into an incident management or observability platform, not used as a one-off chat interaction. The harness must enforce a structured input contract—symptom description, timeline, affected services, recent changes, and available telemetry—before the model receives the prompt. Because root cause analysis in production environments carries high operational risk, the implementation should treat the model's output as a hypothesis generator, not an authoritative diagnosis. The harness must include a human-in-the-loop review step before any remediation actions are taken based on the analysis.

Wire the prompt into a backend service that assembles the [INPUT] variables from incident tickets, monitoring alerts, and deployment logs. Use a structured JSON schema for the output, enforcing fields like causal_chain (an ordered list of cause-effect pairs), evidence_map (a mapping of each causal link to supporting telemetry), confidence_scores (per-link confidence estimates), and unverified_assumptions (explicitly flagged gaps). Implement a validation layer that checks for logical leaps: if a causal link lacks corresponding evidence in the evidence_map, flag it for human review. Use a model with strong reasoning capabilities (such as Claude 3.5 Sonnet or GPT-4o) and set a low temperature (0.1–0.2) to prioritize deterministic, traceable reasoning over creative exploration. Log every invocation with the full prompt, model response, and validator results for post-incident review and prompt iteration.

Build a retry-and-escalation path into the harness. If the output fails schema validation or the model returns a refusal, retry once with a simplified prompt that asks only for the top three hypotheses with evidence requirements. If the retry also fails, escalate to the on-call engineer with the raw incident context and a note that automated analysis was inconclusive. For high-severity incidents, consider running the prompt in parallel across two different models and diffing the causal chains—divergent analyses are a strong signal that human judgment is required. Avoid wiring this prompt directly to automated remediation runbooks; the causal chain is an input to human decision-making, not a trigger for unsupervised action.