Error-Budget-Aware Severity Calibration Prompt
Calibrate an incident's severity against actual SLO impact and remaining error budget — instead of gut feel — so the team neither under-responds to a budget-burning event nor over-mobilizes for a cosmetic one, getting the response size right the first time.
- Target user
- Incident commanders and on-call SREs setting severity
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior SRE who sets incident severity by reasoning from SLOs and error budget, not from alarm volume. Help me calibrate this incident's severity. Propose a level with reasoning; the IC decides, and your call is advisory only. Inputs: - Affected SLO(s): [WHAT SLI / TARGET / WINDOW] - Current burn: [ERROR RATE OR LATENCY VS. TARGET, NOW] - Remaining error budget: [BUDGET LEFT THIS WINDOW, IF KNOWN] - Scope: [USERS / TENANTS / REGIONS AFFECTED, AND WHETHER REVENUE/SAFETY PATHS] - Our severity rubric: [PASTE SEV DEFINITIONS, OR LET ME KNOW YOU'RE ASSUMING STANDARD ONES] Produce a severity calibration: 1. **Quantify the impact** — translate the symptom into SLO terms: how fast is this burning error budget, and how long until the budget is exhausted at the current rate? 2. **Map to the rubric** — place the incident on my severity scale (or a standard SEV1–4) and justify it against the rubric's criteria, not against how loud the alerts are. 3. **Surface the swing factors** — what would push this up a level (acceleration, a revenue/safety path, spreading scope) and what would push it down (a fallback engaging, off-peak timing). 4. **Recommend response size** — the proportionate response: who to page, whether to open a bridge, whether to declare publicly — matched to the severity, so the team neither under- nor over-mobilizes. 5. **State the re-evaluate trigger** — the specific metric change that should prompt re-calibrating severity. Output format: proposed severity | budget-burn math | rubric justification | up/down swing factors | recommended response | re-evaluate trigger. Propose only; this is advisory; the IC owns the severity call and the page list.
Why this prompt works
Mis-calibrated severity is a hidden MTTR tax that cuts both ways. Under-call an incident and the right people don’t get paged, mitigations wait, and a budget-burning event drags far longer than it should. Over-call it and you mobilize a war room for a cosmetic glitch, training the team to ignore the next page. Getting severity right the first time sizes the response correctly, and this prompt grounds that call in SLO impact and error-budget burn rather than the volume of firing alerts.
The core move is translating symptoms into budget terms: not “errors are up” but “at this rate the monthly budget is gone in ninety minutes.” That framing converts a vague sense of badness into a quantified urgency the rubric can act on, and it separates incidents that are loud but harmless from ones that are quiet but genuinely burning the SLO. Anchoring severity to the rubric’s written criteria rather than to alarm noise is precisely the discipline that keeps response size proportionate.
The guardrails keep this advisory. Severity decides who gets woken at 3 a.m. and how many people drop what they’re doing, so the prompt is explicit that it proposes a level and the IC owns the call. It also flags that the math is only as trustworthy as the SLO inputs — a stale budget number or an SLI that misses the real user pain produces a confidently wrong level. The model sharpens the judgment; the human still makes it.
Related prompts
-
Blast-Radius and Dependency Mapping Prompt
Turn a failing component plus its dependency graph into a scoped blast-radius map — what is affected, what is merely downstream, and what is safe — so the team scopes the incident in minutes instead of guessing at impact.
-
First-5-Minutes Triage Prompt
From the alert alone, decide severity, estimate blast radius, and route to the right owner in the opening minutes — so the incident lands with the people who can fix it instead of bouncing, cutting time-to-triage.