Order what to check during an incident
Turns a symptom into a check sequence, narrowing scope before guessing at causes.
| Category | Development › Deploy & operations |
|---|---|
| Tags | AnalyzingChecklistDeveloper |
Help me triage this incident. Answer in this order: **1. Mitigation before diagnosis.** What would restore service now, even without knowing the cause — rollback, scale, disable a feature, fail over, shed load. *Say this first. Understanding the cause is not the on-call objective.* **2. Blast radius.** What is affected and what is not, and how to confirm the boundary quickly. **3. Check sequence.** Ordered so each check eliminates about half of what remains. For each: what to run, and what each outcome rules out. **4. Recent changes.** Which of the changes I listed could produce this symptom, ranked. Correlation with deploy time is the strongest single signal and is worth checking before anything clever. **5. What the symptom already rules out** before I run anything. **6. Data-loss risk** — anything in the mitigation or the diagnosis that could destroy state. Flag it separately and loudly. Rules: - *Do not present a most-likely cause as a conclusion.* Give the check that would confirm it. - If a mitigation is irreversible, say so before recommending it. - Note which checks are safe under load and which will make things worse.
After pasting, fill in the fields at the bottom (Symptom · Recent changes · System)
What this prompt does
The danger during an incident is committing to one plausible cause. This puts recovery first and orders checks so each one eliminates roughly half the possibilities.