Root Cause Analysis
Root Cause Analysis From Symptoms
Walk a messy incident or business miss through causes, evidence, and the one change that would stop a repeat.
The Prompt
root-cause-analysis-from-symptoms.md
Facilitate a root cause analysis. Separate facts from guesses. Problem: {{problem}} When it showed up: {{when}} Impact: {{impact}} What we already know: {{facts}} What we tried: {{tried}} Work through: 1. Problem statement (is / is not, where, when) 2. Timeline 3. 5 Whys - stop when a why is a guess, and label it 4. Two alternative causes that still fit the facts 5. The check that would distinguish them 6. Corrective action vs. detection (so it cannot silently return) Do not blame a person when a process, tool, or incentive is the cause.
Negative prompt
Included when you copy the prompt
Do not invent logs, metrics, timelines, or witness accounts that are not in {{facts}}. Do not stop at a person as the root cause when a process, tool, config, or incentive better explains the evidence. Do not treat guesses as facts - label every speculative why. Do not propose a corrective action that only detects the failure without preventing it, or only prevents it without a detection signal. Do not pad with generic "improve communication" or "be more careful" recommendations. Do not collapse alternative causes into one preferred story without a distinguishing check.
Fill in your details below - this prompt updates as you type, then copy it.
Fill in your details
0 of 5 filled. Preview updates as you type - then copy the finished prompt (negative prompt included when present).
root-cause-analysis-from-symptoms.md
Prompt preview
Facilitate a root cause analysis. Separate facts from guesses. Problem: {{problem}} When it showed up: {{when}} Impact: {{impact}} What we already know: {{facts}} What we tried: {{tried}} Work through: 1. Problem statement (is / is not, where, when) 2. Timeline 3. 5 Whys - stop when a why is a guess, and label it 4. Two alternative causes that still fit the facts 5. The check that would distinguish them 6. Corrective action vs. detection (so it cannot silently return) Do not blame a person when a process, tool, or incentive is the cause.
Examples
Example input
Problem: Checkout API p95 latency spiked from 180ms to 2.4s during peak hours. When it showed up: Tuesday 18:40 - 21:10 UTC, then again Wednesday same window. Impact: Cart conversion dropped ~11% in those windows; support saw 40 "payment spinning" tickets. What we already know: - Error rate stayed under 0.3%; timeouts rose from 0.1% to 1.8%. - DB CPU on primary was 92% during the windows; replica lag hit 14s. - Deploy of "recommendation ranking v3" went out Monday 16:00; no schema change. - New ranking job writes cache keys via the same Redis pool the checkout session store uses. What we tried: Restarted API pods (temporary relief ~20 min). Scaled API replicas 4→8 (no lasting effect). Rolled back ranking v3 on Wednesday night - spike stopped.
What you should get
1. Problem statement Is: Checkout latency and timeouts spike Tue/Wed ~18:40 - 21:10 UTC while DB primary CPU and Redis contention rise. Is not: Widespread 5xx, schema migration failure, or payment-provider outage (error rate stayed low; provider status green). Where: Checkout API path + shared Redis + primary DB. When: Peak evening windows after ranking v3 deploy. 2. Timeline Mon 16:00 - ranking v3 deploy (writes Redis via shared pool). Tue 18:40 - first latency spike; DB CPU 92%, replica lag 14s. Tue ~21:10 - window ends. Wed - same pattern. Wed night - ranking v3 rollback; spike stops. 3. 5 Whys Why latency? Checkout waits on Redis/DB longer (timeouts up; evidence: metrics). Why Redis/DB slow? Contention/load during peak (evidence: CPU 92%, lag 14s). Why extra load then? Ranking job writes heavy cache traffic on shared Redis (evidence: same pool; spike ends after rollback). Why shared pool? Ranking and checkout sessions share one Redis instance (fact from notes). Why no isolation? [GUESS] Capacity planning did not treat ranking writes as peak-hour risk - label as hypothesis until we confirm pool config / runbooks. 4. Alternative causes that still fit A) Ranking queries hit primary DB harder than expected (not only Redis). B) Unrelated evening cron / batch job coincided with deploy (less likely after rollback cured it, but still possible if rollback also paused a cron). 5. Distinguishing check Replay peak load with ranking writes isolated to a dedicated Redis DB/instance while checkout keeps the original pool; compare checkout p95 and DB CPU. Separately, check slow-query log for ranking-shaped queries on primary during the window. 6. Corrective vs detection Corrective: Move ranking cache writes off the checkout Redis pool (or rate-limit / off-peak the job); confirm in staging under peak synthetic load. Detection: Alert when checkout Redis latency p95 > 50ms or primary CPU > 80% during peak, plus a deploy checklist item for shared-resource impact.
When to use this prompt
Use it when
- You need help with managers.
- You need help with engineers.
- You need help with ops.
Skip it when
- You only need a one-line ask with no constraints, format, or context.
- You cannot supply the fill-in details the template asks for.
- A different category or tool-specific workflow fits the job better.
How to get a good result
Done when
1. Problem statement Is: Checkout latency and timeouts spike Tue/Wed ~18:40 - 21:10 UTC while DB primary CPU and Redis contention rise. Is not: Widespread 5xx, schema migration failure, or payment-provider outage (error rate stayed low; provider status green). Where: Checkout API path + shared Redis + primary DB. When: Peak evening windows after ranking v3 deploy. 2. Timeline Mon 16:00 - ranking v3 deploy (writes Redis via shared pool). Tue 18:40 - first latency spike; DB CPU 92%, replica lag 14s. Tue ~21:10 - window ends. Wed - same pattern. Wed night - ranking v3 rollback; spike stops. 3. 5 Whys Why latency? Checkout waits on Redis/DB longer (timeouts up; evidence: metrics). Why Redis/DB slow? Contention/load during peak (evidence: CPU 92%, lag 14s). Why extra load then? Ranking job writes heavy cache traffic on shared Redis (evidence: same pool; spike ends after rollback). Why shared pool? Ranking and checkout sessions share one Redis instance (fact from notes). Why no isolation? [GUESS] Capacity planning did not treat ranking writes as peak-hour risk - label as hypothesis until we confirm pool config / runbooks. 4. Alternative causes that still fit A) Ranking queries hit primary DB harder than expected (not only Redis). B) Unrelated evening cron / batch job coincided with deploy (less likely after rollback cured it, but still possible if rollback also paused a cron). 5. Distinguishing check Replay peak load with ranking writes isolated to a dedicated Redis DB/instance while checkout keeps the original pool; compare checkout p95 and DB CPU. Separately, check slow-query log for ranking-shaped queries on primary during the window. 6. Corrective vs detection Corrective: Move ranking cache writes off the checkout Redis pool (or rate-limit / off-peak the job); confirm in staging under peak synthetic load. Detection: Alert when checkout Redis latency p95 > 50ms or primary CPU > 80% during peak, plus a deploy checklist item for shared-resource impact.
Common mistakes
- Leaving problem, when, impact vague - the model then invents placeholders.
- Asking ChatGPT, Claude, or Gemini for a shorter answer after a long structured prompt - that throws away the format rules.
- Stopping when the first draft appears instead of checking it against the success criteria below.
FAQ
- What do I fill in before I copy this prompt?
- Replace these placeholders with your details: problem, when, impact, facts, tried. Required fields are marked on the page. The prompt text updates as you type.
- Which AI tools is this prompt written for?
- It works best with ChatGPT, Claude, Gemini. Copy the filled prompt and paste it into the tool you already use.
- What should a good result look like?
- 1. Problem statement Is: Checkout latency and timeouts spike Tue/Wed ~18:40 - 21:10 UTC while DB primary CPU and Redis contention rise. Is not: Widespread 5xx, schema migration failure, or payment-provider outage (error rate stayed low; provider status green). Where: Checkout API path + shared Redis + primary DB. When: Peak evening windows after ranking v3 deploy. 2. Timeline Mon 16:00 - ranking v3 deploy (writes Redis via shared pool). Tue 18:40 - first latency spike; DB CPU 92%, replica la…
- What are common mistakes with this prompt?
- Leaving problem, when, impact vague - the model then invents placeholders. Asking ChatGPT, Claude, or Gemini for a shorter answer after a long structured prompt - that throws away the format rules. Stopping when the first draft appears instead of checking it against the success criteria below.
Best for
- Managers
- Engineers
- Ops
Related Prompts
More prompts like this — same topic and style.