Alert Enrichment: Context on the Page Prompt
Turn a bare alert into an enriched page — what fired, where it lives, and what changed recently — so the responder acknowledges with context instead of cold, cutting time-to-acknowledge.
- Target user
- On-call SREs and the platform team building paging context
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior SRE who has spent years being woken at 3am by alerts that say nothing useful. You know the gap between "page received" and "page understood" is dead time that inflates MTTR. Help me turn a bare alert into an enriched, scannable page. Paste your raw inputs below: - The firing alert exactly as paged: [ALERT PAYLOAD / LABELS / ANNOTATIONS] - The service and its dependencies: [SERVICE NAME + UPSTREAM/DOWNSTREAM DEPS] - Recent changes in the blast window: [DEPLOYS / CONFIG CHANGES / FEATURE FLAGS, LAST 6H] - Anything else attached to the page: [DASHBOARD LINKS / RUNBOOK URL / OWNER] Do the following: 1. **Restate the page in one human sentence** — what fired, on what service, breaching which threshold, since when. No jargon the half-asleep responder has to decode. 2. **Localize it** — name the specific service, environment, region/cluster, and the upstream/downstream most likely involved. Say what is and is not in scope from the labels alone. 3. **Surface recent changes** — list deploys/config/flag changes inside the blast window, newest first, and flag which ones correlate in time with the alert. Mark correlation, not causation. 4. **Assemble the context block** — the 5 things the responder needs in the first 60 seconds: the affected SLO, the current vs. threshold value, the most relevant dashboard, the owning team, and the matching runbook (or "none found"). 5. **Flag what's missing** — note any context you could not derive (no runbook, no recent-change data) so the responder knows the gap rather than assuming there is none. Output format: a 4-line "PAGE SUMMARY" header, then a "RECENT CHANGES" table (change | time | correlation), then a "CONTEXT" bullet list. For every change you call out as suspicious, append a single read-only verification command (e.g. `kubectl rollout history`, `git log --since`) the responder can run to confirm — propose and rank by likelihood, but never assert a cause and never run anything against production yourself.
Why this prompt works
This prompt attacks the acknowledge phase of the MTTR funnel, where surprisingly large amounts of time leak. A bare page forces the responder to do manual reconnaissance — open three tabs, find the dashboard, ask in Slack what deployed — before they can even decide whether to act. Compressing that reconnaissance into a pre-assembled context block lets the responder ack with understanding instead of acking and then starting cold.
The structure deliberately separates restatement, localization, and recent-change surfacing because each answers a different first-60-seconds question: what is broken, where, and what touched it. Recent changes are ranked by temporal correlation but explicitly framed as correlation-not-causation, so the enrichment narrows attention without prematurely committing the team to a hypothesis.
Crucially, the AI stays in an advisory role: it proposes likely-relevant changes and hands the responder a read-only command to verify each one, rather than declaring a root cause. That keeps the human in control at exactly the moment when a wrong, confident guess would send the whole incident down a dead end and increase time-to-recover.
Related prompts
-
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.
-
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.