Mitigate-Now vs. Keep-Diagnosing Decision Prompt
In the middle of a live incident, decide whether to apply an available mitigation immediately or keep diagnosing for root cause — so you stop the customer bleeding at the earliest safe moment instead of chasing 'why' while the clock runs, cutting time-to-restore.
- Target user
- On-call SREs and incident commanders under active customer impact
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior incident commander helping an on-call engineer make the single most MTTR-relevant call during a live incident: **mitigate now, or keep diagnosing?** The goal is to restore service at the earliest *safe* moment, not to satisfy curiosity about root cause while customers are still impacted.
Paste the current situation:
- What is broken and who it affects: [USER-FACING SYMPTOM + BLAST RADIUS]
- How long it has been impacting: [TIME SINCE IMPACT STARTED]
- Mitigations available to us right now: [ROLLBACK / FAILOVER / FEATURE-FLAG OFF / SCALE-UP / TRAFFIC SHIFT / RESTART — with any known side effects]
- What we currently believe is happening: [LEADING HYPOTHESIS + CONFIDENCE]
- Constraints: [DATA-LOSS RISK, STATEFUL SYSTEMS, CHANGE-FREEZE, COMPLIANCE, ETC.]
Work through this:
1. **Separate mitigation from root cause.** State plainly that restoring service and understanding the cause are two different goals, and that a mitigation does not require knowing the root cause. List which available actions are *reversible* and *low-blast-radius* versus which are risky or one-way.
2. **Evaluate each mitigation** on: expected time-to-effect, likelihood it stops the impact, reversibility, and worst-case side effect. Flag any mitigation that could destroy data, corrupt state, or widen the blast radius — those are not "quick wins."
3. **Make the call.** Recommend either (a) apply a specific mitigation now, or (b) continue diagnosing for a bounded time. If you recommend waiting, give an explicit timebox ("diagnose for up to N minutes, then mitigate regardless") so the team cannot drift into an open-ended rabbit hole.
4. **Preserve evidence.** If mitigating destroys diagnostic signal (rolling pods, clearing state), list the read-only captures to take first — logs, a heap/thread dump, current metrics snapshot, a copy of the bad config — so root-cause analysis is still possible afterward.
5. **Define the verification.** State the exact signal that will confirm the mitigation worked (error rate returns to baseline, success rate recovers) and the rollback trigger if it does not.
Output format: a "MITIGATION DECISION" card with fields RECOMMENDATION (mitigate-now / diagnose-with-timebox), CHOSEN ACTION, EXPECTED TIME-TO-EFFECT, REVERSIBILITY, EVIDENCE TO CAPTURE FIRST, VERIFICATION SIGNAL, ROLLBACK TRIGGER. Rank options by confidence and be explicit about uncertainty. Propose the action and the read-only captures, but do not execute the mitigation, roll back production, or toggle flags yourself — the human applies the change and owns the outcome.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
The most expensive minutes in many incidents are spent diagnosing when the team could already be mitigating. Engineers are trained to find root cause, and that instinct — admirable in a post-mortem — actively inflates MTTR during a live outage. This prompt targets the time-to-restore phase by forcing the one distinction people forget under pressure: restoring service and understanding the cause are separate goals, and you rarely need the second to achieve the first.
By requiring an explicit timebox on any “keep diagnosing” recommendation, it prevents the open-ended rabbit hole where a team debugs for forty minutes while a one-command rollback was available the whole time. And by scoring every mitigation on reversibility and worst-case side effect, it stops the opposite failure — a panicked destructive action that turns a small incident into a large one.
The evidence-capture step is what makes this safe to use repeatedly: mitigating first is only wise if you do not lose the ability to root-cause later. Keeping the human as the one who actually applies the change, while the AI proposes the option and the read-only captures, means the model accelerates the decision without ever being the thing that touches production.
Related prompts
-
War-Room Role Assignment Prompt
When a major incident pulls a crowd into the bridge, assign clear roles — commander, comms, scribe, ops leads — from who is actually present, so coordination overhead stops eating MTTR and every workstream has a named owner instead of five people debugging the same thing.
-
Runbook and Next-Step Surfacer Prompt
Match the live symptom to the right runbook and surface the exact command to run now — so the responder acts from a known-good procedure instead of improvising, shortening time-to-mitigate.
-
Alert Correlation Prompt: Collapse a Storm Into One Incident
Take a flood of simultaneous alerts and group them into a single incident with one probable originating cause, so responders triage one signal instead of fifty — cutting the time lost sorting noise from the real failure.
-
Customer-Impact Quantifier Prompt
Turn raw incident signals into a defensible estimate of how many users, which segments, and how much revenue are affected — so severity, comms, and prioritization are sized on impact instead of gut feel, and the response matches the real blast radius.
More Reduce MTTR with AI prompts & error guides
Browse every Reduce MTTR with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.