Verified against Claude Code · 2026-07-21
Turn a raw production stack trace into a scoped root-cause hypothesis, not a guess
An incident-triage prompt that has Claude Code correlate a raw stack trace against recent deploys and error-frequency data before proposing a root cause, and separates an immediate mitigation from a permanent fix so the two are never accidentally conflated under time pressure.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are triaging a live production incident from the evidence below, not writing a general bug fix. Speed matters, but a wrong root cause acted on quickly is worse than a right one reached ten minutes later, so do not skip a step to move faster. STACK TRACE AND LOGS TypeError: Cannot read properties of undefined (reading 'total') at calculateShipping (checkout/shipping.ts:42), 340 occurrences in the last hour, all on the /checkout/review endpoint. RECENT DEPLOYS TO THIS SERVICE 14:02 UTC — merged 'add international shipping zones' to checkout/shipping.ts; 09:15 UTC — unrelated deploy to the auth service. HOW OFTEN THIS IS HAPPENING Zero occurrences before 14:05 UTC today, then a steady 5 to 6 per minute since, matching a spike right after the 14:02 deploy. WHAT IS ACTUALLY AFFECTED Only checkouts where the shipping address is outside the newly added international zones list; domestic checkout is unaffected. CAN THIS BE ROLLED BACK The 14:02 deploy can be reverted with a single revert commit and redeploy, roughly 4 minutes end to end. TRIAGE PROCESS 1. Read the stack trace literally first — the exact function, file, and line where it actually threw, not the feature area it happens to belong to. State that line before speculating about anything upstream of it. 2. Cross-reference the timing of Zero occurrences before 14:05 UTC today, then a steady 5 to 6 per minute since, matching a spike right after the 14:02 deploy. against 14:02 UTC — merged 'add international shipping zones' to checkout/shipping.ts; 09:15 UTC — unrelated deploy to the auth service.. If the error's onset lines up with a specific deploy, that deploy is the leading hypothesis and must be named specifically, not gestured at as 'a recent change.' If the timing does not line up with any deploy, say so explicitly — an error with no deploy correlation points toward external factors such as a dependency's own outage, a data condition that only now occurs, or load, not toward the most recent commit by default. 3. Search the codebase for the actual code at the failing line and trace backward far enough to state a mechanism, not just a location — what specific input or state condition reaches that line and causes it to fail, stated concretely enough that it could be reproduced deliberately. 4. State a confidence level on the root cause — confirmed, likely, or speculative — and say exactly what additional evidence would move a likely or speculative hypothesis to confirmed, rather than presenting a guess with the same confidence as a verified fact. MITIGATION VERSUS FIX — KEEP THESE SEPARATE Propose the fastest safe way to stop the bleeding right now, given The 14:02 deploy can be reverted with a single revert commit and redeploy, roughly 4 minutes end to end., and separately propose the actual permanent fix for the mechanism identified in step three. Do not present the mitigation as the fix, and do not skip the mitigation while working out the fix if the error is actively affecting Only checkouts where the shipping address is outside the newly added international zones list; domestic checkout is unaffected. right now. CONSTRAINTS - Do not propose a fix for a mechanism you have not stated with the confidence label above at likely or confirmed. - Do not treat a stack trace's top frame as the necessarily wrong line — sometimes the top frame is exactly where the bug lives; do not manufacture a more complicated theory because the obvious one feels too simple. - If multiple deploys landed close together, name each one and which specific change in each is the more plausible suspect, rather than blaming the batch as a whole. OUTPUT Root cause with confidence label, mitigation, permanent fix, and what would raise confidence if it is not already confirmed.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Under genuine production time pressure, a model's fastest path to a plausible-sounding answer is to pattern-match the error message to a familiar bug category and propose a fix for that category, which is precisely how an incident gets mitigated for the wrong reason — the fix looks reasonable, the error rate might even drop by coincidence, and the actual mechanism ships unaddressed to resurface later under slightly different conditions. Requiring the deploy-timing cross-reference before any hypothesis is stated exploits the single most reliable signal available during an incident: production code that was stable yesterday and is throwing today changed for a reason, and that reason is disproportionately likely to be something that shipped in the window the error's onset actually lines up with, which is a checkable fact rather than an inference from the error message's vocabulary alone. Separating mitigation from permanent fix as two explicitly distinct outputs matters because the two have different acceptable error bars — a mitigation only needs to plausibly stop the immediate bleeding and can be safely wrong about the deeper mechanism, while a permanent fix that is wrong about the mechanism will not actually prevent recurrence, and collapsing the two into one recommendation risks either delaying an urgently needed mitigation while root-causing is finished, or shipping an under-verified permanent change under the same time pressure that a quick mitigation would have absorbed instead. The confidence label — confirmed, likely, or speculative — forces the model to distinguish what it has actually traced through code from what it is inferring from correlation alone, and naming what evidence would raise that confidence gives a human responder a concrete next action rather than a hedge with no path forward. The instruction not to manufacture a more complicated theory when the obvious one from the top stack frame is simple exists because incident response has its own bias in the opposite direction from patient debugging — a stack trace's literal top frame is very often exactly where the defect lives, and a model trained to look thorough can talk itself into a more elaborate root cause than the evidence actually supports, wasting the exact minutes an incident cannot spare.
What you get back
Root cause (confirmed): calculateShipping in checkout/shipping.ts:42 reads zone.total on a zone lookup that returns undefined for any address outside the newly added international zones list added in the 14:02 deploy; the lookup was never given a fallback for an address matching no configured zone. Mitigation: revert the 14:02 deploy now — 4 minutes to redeploy, restores domestic-only shipping which was working correctly before. Permanent fix: add an explicit not-found branch in the zone lookup that either falls back to a default rate or returns a clear checkout error, then reintroduce international zones behind that guard.
Verified against
Claude Code Sonnet 4.6 · 2026-07-21
Changelog
- 2026-07-21 — Initial publish, verified against Claude Code incident triage (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
