Runbook Template (Markdown) for On-Call and Operations
A runbook template in plain Markdown for the person who gets paged at 3 a.m. It opens with the trigger and the impact, gives a triage flowchart, shows each command with its expected output, and ends with rollback and escalation. Copy it, download the .md file, or keep it in the same repository as the service.
Free to use, no attribution required (CC0).
Runbook: {{Alert or operation name}}
| Service | {{Service name}} |
| Owner | {{Team or name}} |
| On-call channel | {{Channel or paging policy}} |
| Severity if unresolved | {{SEV1 / SEV2 / SEV3}} |
| Last tested | {{YYYY-MM-DD}} by {{Name}} |
| Next review | {{YYYY-MM-DD}} |
When to use this
The alert name, the symptom, the threshold. Paste the alert text so searching for it finds this page.
- Alert:
{{alert_name}} - Symptom: {{What the user or the dashboard shows}}
- Do not use if: {{When another runbook applies — link}}
Impact
- Who is affected: {{...}}
- What breaks: {{...}}
- Time budget: {{How long before this becomes a SEV1}}
Before you start
- Access to {{system, role, VPN}}
- Tools: {{kubectl, psql, cloud console}}
- Dashboards open: {{link}}
- Change freeze or maintenance window checked: {{link}}
Triage
Edit the labels so the flowchart matches your service.
flowchart TD
A[Alert fires] --> B{Is the service up?}
B -- No --> C[Go to step 1: restart and check logs]
B -- Yes --> D{Error rate above threshold?}
D -- Yes --> E[Go to step 3: roll back the last change]
D -- No --> F[Check for a false alarm and tune the alert]
C --> G{Recovered?}
G -- Yes --> H[Verify and close]
G -- No --> I[Escalate]
E --> G
Procedure
Step 1. {{Check the current state}}
{{command}}
Expected: {{expected output}}
If different: {{what it means and what to do}}
Step 2. {{Mitigate}}
{{command}}
Expected: {{expected output}}
If different: {{...}}
Risky step: {{what can go wrong}}. Rollback: see "Rollback" below.
Step 3. {{Next action}}
{{command}}
Expected: {{...}}
If different: {{...}}
Verify
- {{Metric or health check is back to normal: link to dashboard}}
- {{A test request succeeds: command}}
- {{No new alerts for N minutes}}
Rollback
- {{How to undo step 2}}
- {{How to undo step 3}}
- {{Confirm the previous state}}
Escalation
| Condition | Who | How |
|---|---|---|
| No progress after {{N}} minutes | {{Secondary on-call}} | {{Paging policy or phone}} |
| Data loss suspected | {{Incident commander}} | {{Channel}} |
| Customer-visible outage | {{Communications owner}} | {{Status page, template link}} |
Communication
- Update {{channel}} when you start, every {{N}} minutes, and when resolved.
- Status page: {{link and who updates it}}
Known problems
| Symptom | Cause | Fix |
|---|---|---|
| {{...}} | {{...}} | {{...}} |
Background (read after the incident)
{{How the system works, why the steps work, links to architecture pages.}}
After the incident
- Fix anything in this runbook that was wrong or unclear
- Write a postmortem if the incident met the criteria: {{link}}
Revision history
| Date | Author | Change |
|---|---|---|
| {{YYYY-MM-DD}} | {{Name}} | First version |
# Runbook: {{Alert or operation name}}
| | |
|---|---|
| **Service** | {{Service name}} |
| **Owner** | {{Team or name}} |
| **On-call channel** | {{Channel or paging policy}} |
| **Severity if unresolved** | {{SEV1 / SEV2 / SEV3}} |
| **Last tested** | {{YYYY-MM-DD}} by {{Name}} |
| **Next review** | {{YYYY-MM-DD}} |
## When to use this
*The alert name, the symptom, the threshold. Paste the alert text so searching for it finds this page.*
- **Alert:** `{{alert_name}}`
- **Symptom:** {{What the user or the dashboard shows}}
- **Do not use if:** {{When another runbook applies — link}}
## Impact
- **Who is affected:** {{...}}
- **What breaks:** {{...}}
- **Time budget:** {{How long before this becomes a SEV1}}
## Before you start
- [ ] Access to {{system, role, VPN}}
- [ ] Tools: {{kubectl, psql, cloud console}}
- [ ] Dashboards open: {{link}}
- [ ] Change freeze or maintenance window checked: {{link}}
## Triage
*Edit the labels so the flowchart matches your service.*
```mermaid
flowchart TD
A[Alert fires] --> B{Is the service up?}
B -- No --> C[Go to step 1: restart and check logs]
B -- Yes --> D{Error rate above threshold?}
D -- Yes --> E[Go to step 3: roll back the last change]
D -- No --> F[Check for a false alarm and tune the alert]
C --> G{Recovered?}
G -- Yes --> H[Verify and close]
G -- No --> I[Escalate]
E --> G
```
## Procedure
### Step 1. {{Check the current state}}
```bash
{{command}}
```
**Expected:** `{{expected output}}`
**If different:** {{what it means and what to do}}
### Step 2. {{Mitigate}}
```bash
{{command}}
```
**Expected:** `{{expected output}}`
**If different:** {{...}}
> Risky step: {{what can go wrong}}. Rollback: see "Rollback" below.
### Step 3. {{Next action}}
```bash
{{command}}
```
**Expected:** `{{...}}`
**If different:** {{...}}
## Verify
- [ ] {{Metric or health check is back to normal: link to dashboard}}
- [ ] {{A test request succeeds: command}}
- [ ] {{No new alerts for N minutes}}
## Rollback
1. {{How to undo step 2}}
2. {{How to undo step 3}}
3. {{Confirm the previous state}}
## Escalation
| Condition | Who | How |
|---|---|---|
| No progress after {{N}} minutes | {{Secondary on-call}} | {{Paging policy or phone}} |
| Data loss suspected | {{Incident commander}} | {{Channel}} |
| Customer-visible outage | {{Communications owner}} | {{Status page, template link}} |
## Communication
- Update {{channel}} when you start, every {{N}} minutes, and when resolved.
- Status page: {{link and who updates it}}
## Known problems
| Symptom | Cause | Fix |
|---|---|---|
| {{...}} | {{...}} | {{...}} |
## Background (read after the incident)
{{How the system works, why the steps work, links to architecture pages.}}
## After the incident
- [ ] Fix anything in this runbook that was wrong or unclear
- [ ] Write a postmortem if the incident met the criteria: {{link}}
## Revision history
| Date | Author | Change |
|---|---|---|
| {{YYYY-MM-DD}} | {{Name}} | First version |
Want to see it as a real wiki page? Open this template in the Folio demo, where it is a normal Markdown page.
How to use it
Step 1: Start from the alert. Create one runbook per alert or per recurring operation, and put its link in the alert text. Fill in "When to use this" and "Impact" first.
Step 2: Write steps as exact commands. For each step, give the command, the expected output, and what to do if the output differs. Do the procedure on a staging system while you write.
Step 3: Test it with someone who did not write it. Have another engineer follow it cold, fix every place they hesitated, and set the "last tested" date and the owner.
What makes a good runbook
It is written for a tired reader. Short steps, one action each, commands that can be copied and pasted, and no background reading before the first action. Explanations go in a separate section at the bottom.
Every step says how to know it worked. An expected output after each command removes guessing at the worst time. The runbook should also say what to do if the output does not match.
It has a way out. Rollback or a safe stop for each risky step, and an escalation table with names, channels and the conditions for calling them. A runbook that only moves forward turns a small incident into a large one.
It is tested and owned. Untested runbooks fail the first time they matter. Record the last test date, the owner, and the review cycle, and fix the runbook as part of every incident that used it.
More templates
Questions
- What is the difference between a runbook and a playbook?
- Usage varies. Commonly, a runbook is a precise procedure for a specific task or alert, and a playbook is a broader plan for a type of situation, with decisions and roles. Use whichever word your team uses and make each document do one job.
- What should a runbook contain?
- Trigger, impact, prerequisites and access, triage steps, the procedure with commands and expected results, verification, rollback, escalation contacts, and known problems. This template has a section for each.
- How is a runbook different from an SOP?
- An SOP describes a routine business process. A runbook describes an operational procedure in a technical system, often under time pressure, with commands and failure branches. They share the same logic, so the SOP template is a good starting point for non-technical processes.
- Where should runbooks be stored?
- In version control next to the service they describe, or in a wiki that on-call engineers can reach when your main infrastructure is down. Check that you can open them without your own VPN or single sign-on.
- Can a runbook be automated?
- Many steps can. Start by writing the manual version, then turn the most repeated and least risky steps into scripts, and call the script from the runbook with the expected output. Keep the manual path as a fallback.
Updated 11 October 2026.
Runbooks in Git, next to the service
In Folio a runbook is a Markdown page in the same Git repository as the service it describes, so changes go through the normal review and the history shows who changed a command. Code blocks, tables and Mermaid flowcharts render in the editor, and the built-in assistant can answer "what do I do when the queue backs up?" from the runbook pages; with a Sources: rule in its .agent folder it shows which page it used.