Runbook Generator
Generate a complete on-call runbook in Markdown. Symptoms, diagnostic commands, mitigation steps, rollback procedure, escalation path, and dashboards — all from one form. Copy or download.
Identifier this runbook is keyed off (matches your alerting rule)
Affected service name
How urgent is this
Who owns the response
Where to coordinate
What this alert means in plain language
What customers / dashboards show. One per line.
Copy-paste commands to confirm and scope the issue
Numbered steps the responder should follow
If a deploy is implicated
Who to escalate to and when
One URL per line
Other alerts that often fire alongside this one
Fill in the fields above and click Generate Runbook.
The generated Markdown will appear here, ready to copy or download as a .md file.
Automate your incident response
Reduce MTTR by 90% with AI-powered root cause analysis. Free to start.
The 3-AM rule of runbook writing
Imagine you have just been paged at 3 AM. You do not own this service. You have never seen this alert before. You have five minutes to act before the on-call rotation gets escalated. What does the runbook need to tell you?
That mental model produces the right structure: a one-line summary (what does this mean?), a few diagnostic commands (is this real and what is the scope?), numbered mitigation steps (what do I do?), a rollback procedure (if a deploy is implicated), an escalation path (when to wake somebody else up), and links to dashboards. Anything else is footnotes — keep the main path linear and copy-pasteable.
What separates great runbooks from mediocre ones
- Diagnostic commands you can paste — not "check the dashboard" but the actual
kubectl,curl, or PromQL query. The responder should be able to confirm the issue in under a minute. - Numbered mitigation steps in order. Branching is OK ("if X then Y else Z") but always commit to a default path.
- A rollback procedure with the exact command. Most production incidents are deploy-related; rollback being one paste away pays for itself.
- Explicit escalation triggers — not "escalate if it gets bad," but "page Tier 2 after 30 minutes if not resolved." Time-bound and unambiguous.
Runbooks and AI SRE agents
Runbooks used to be just for humans. Now AI SRE agents read them too — Uptimes.ai\'s agent ingests linked runbooks during investigation and uses them as candidate actions. This means a well-structured runbook now has compounding value: humans benefit, the agent benefits, and the agent\'s automated remediations can be derived directly from your mitigation section.
This is a meaningful shift in how to think about runbook quality. The same clarity that helps a sleepy human at 3 AM also helps an automated system reason about what to do — and bad runbooks become a bottleneck for both.