Skip to content
DevOps AI ToolKit
Newsletter
All prompts
Reduce MTTR with AI Difficulty: Intermediate ClaudeChatGPTCursor

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

Newsletter

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 2,104 DevOps AI prompts
  • One practical workflow email per week