What this prompt does
This prompt writes an on-call runbook built for a tired human at 3am — short bullets and exact commands, not prose. It casts the assistant as a senior DevOps engineer and supplies four context variables: [service_name], [platform], [datastore], and [tooling]. The deliverables are a health summary with the service's SLOs, common alerts and what each actually means, first-five-minutes triage in order, the top five incident scenarios each with step-by-step mitigation commands, the escalation path with who to page and when, and the rollback procedure with links to the dashboards and logs that matter.
The structure works because a runbook written for a calm afternoon is useless during the incident it was meant for. By demanding copy-paste commands inline, the prompt removes the worst failure mode: someone half-awake reconstructing a kubectl or psql invocation from memory under pressure. Naming [tooling] (PagerDuty, Grafana, CloudWatch) makes the alerts and escalation steps concrete to your stack, and the first-five-minutes section imposes an ordered triage so responders don't freeze or flail.
When to use it
- The day a critical service goes live, before its first real page
- When an existing runbook is vague prose instead of actionable commands
- When on-call engineers keep paging seniors for steps that should be documented
- When you want a consistent triage order across the whole on-call rotation
- After an incident, to fold the lessons into a refined runbook
- When onboarding new on-call staff to a service they don't know deeply
Example output
You get a scannable runbook: a health-and-SLO summary, an alerts table explaining what each alert means, an ordered first-five-minutes triage checklist, five incident scenarios each with inline mitigation commands, an escalation path naming who to page and when, and a rollback procedure with dashboard and log links in place. The format favors short bullets and copy-paste commands over explanation, so a responder can act without reading paragraphs. The ordering matters as much as the content: the triage checklist is sequenced so the first checks rule out the most common causes, and the escalation path is explicit about the threshold at which you stop debugging alone and pull in a second person.
Pro tips
- Set
[tooling]to your real alerting stack so the alert meanings and escalation steps match what responders actually see - Name
[datastore]precisely so mitigation commands target the right database and cache - Insist every mitigation has exact commands inline; a runbook that says "restart the service" without the command fails at 3am
- Draft it the day the service launches, then refine after each real page rather than waiting for the perfect version
- Replace placeholder dashboard links with real URLs before the runbook goes into rotation
- Have someone unfamiliar with the service dry-run the triage steps to catch missing context
