Extracting recurring patterns from postmortems and making runbooks usable under stress
A runbook read during an incident at two in the morning has to be understandable within seconds, not after five minutes of reading. Claude helps extract recurring patterns from existing incident postmortems, design a structure for the first five minutes under stress, and systematically keep runbooks current after every new incident instead of writing them once and forgetting about them.
Table of Contents
- 1. Why Runbooks Are Usually Outdated or Unusable
- 2. Extracting Recurring Patterns from Existing Postmortems
- 3. Designing a Consistent Runbook Structure with Claude
- 4. Designing a Checklist for the First Five Minutes Under Stress
- 5. Defining Escalation Paths Clearly and Unambiguously
- 6. Generating a Concrete Runbook for a Known Failure Mode
- 7. Systematically Updating Runbooks After Every Incident
- 8. Maintaining Runbooks as Code in a Git Repository
- 9. Limits: Claude Does Not Know Your Internal Access Paths
- 10. Summary
- 11. FAQ
1. Why Runbooks Are Usually Outdated or Unusable
In many teams, runbooks exist only on paper: a wiki article written once two years ago and never touched since, while the system's architecture has changed several times in the meantime. When a new incident occurs, the person on call therefore often relies not on the runbook but on their own experience or a colleague who happens to be reachable, which unnecessarily lengthens response time and turns individual people into irreplaceable single points of failure.
Claude fundamentally changes the economics of this maintenance work: instead of laboriously reconstructing a runbook from memory, structured drafts can be extracted from already written postmortems within minutes, needing only subject matter review and refinement afterward. That lowers the barrier to actually keeping runbooks current considerably, since the most expensive part, the first draft, gets practically automated.
2. Extracting Recurring Patterns from Existing Postmortems
Most teams accumulate a substantial number of postmortem documents over months and years without systematically analyzing them for recurring patterns. Claude is excellent for reading in several postmortems of the same system and working out commonalities, for example that three out of five database incidents started with the same symptom, a rising number of open connections shortly before the actual outage.
That pattern analysis lets you derive a generic runbook for the symptom class database connection pool exhausted, one that applies not just to the one concrete incident but to the entire category of similar future incidents. That is considerably more valuable than a runbook per individual historical incident, because on-call staff under stress rarely have time to pick the right one from a long list of similar documents.
# Example prompt for Claude
"Here are five postmortems from database incidents over
the last six months (attached as markdown files). Identify
recurring symptoms, shared root causes, and extract a
generic runbook for the symptom class
'connection pool exhausted'."
3. Designing a Consistent Runbook Structure with Claude
A runbook without a consistent structure forces the person on call to first orient themselves within an unfamiliar layout under stress before even starting the actual diagnosis. Claude is good for designing a reusable template that stays identical across every runbook: symptom description, a diagnosis checklist for the first minutes, most likely causes with their respective verification method, concrete immediate actions, and a clear escalation path if the immediate actions do not work.
Once this structure is agreed with the team, Claude can consistently produce every new runbook in exactly this format, which considerably reduces cognitive load when reading under time pressure, because experienced on-call staff know exactly where in the document to find which information, without having to search anew each time.
4. Designing a Checklist for the First Five Minutes Under Stress
The first minutes of an incident often decide whether a problem gets contained quickly or escalates, while at the same time the cognitive capacity of a just woken, stressed person is at its lowest in this phase. Claude helps design a deliberately minimalist checklist limited to a few clearly prioritized steps: grasp current system status at a glance, roughly estimate the affected user population, set the severity level on a fixed scale, and escalate immediately if needed, rather than trying to solve the problem alone.
It matters that this first checklist deliberately contains no deep diagnosis, only triage steps that even a less experienced person can reliably execute under stress. Claude can be asked specifically to review each step for cognitive complexity and simplify it, for example replacing a step with three possible interpretations with a clear yes or no decision.
## First 5 minutes: database connection pool exhausted
1. Open the "DB Connections" Grafana dashboard: is the current
value above 90 percent of the configured limit?
YES -> proceed to step 2
NO -> different runbook, symptom does not match
2. Check affected services: only one service or several?
One service -> immediate action A (restart the service)
Several services -> escalate immediately, step 5
3. Set severity (SEV1 to SEV3) per the team's scale
4. Open the incident channel, post severity and symptom
5. For SEV1: page the secondary on-call immediately via PagerDuty
5. Defining Escalation Paths Clearly and Unambiguously
A common weak point in runbooks is a vaguely worded escalation like inform the team if needed, without naming concrete people, contact channels, or time limits. Claude helps derive a concrete escalation matrix from a description of the team structure, on-call schedules, and severity definitions, one that specifies for every severity level exactly who gets contacted after how much time without progress and through which channel.
It is especially valuable to explicitly ask Claude about gaps in the escalation logic, for example what happens if the primary on-call person does not respond within ten minutes, or how to proceed when an incident affects several teams at once and none of the people involved obviously owns overall responsibility. Such edge cases are often overlooked in a runbook's first draft but weigh particularly heavily during a real incident.
6. Generating a Concrete Runbook for a Known Failure Mode
The value becomes most concrete when you describe a specific, already known failure mode to Claude, for example a payment provider API that responds with HTTP 503 under load, and have it produce a complete runbook containing the symptom description, the most likely causes with verification commands, an immediate action such as activating a fallback payment provider, and the associated escalation level.
Such runbooks can then be tested directly against the real system landscape, with an experienced team member actually running the described verification commands and confirming that the proposed diagnostic paths work in practice. This validation is essential, since Claude does not know your team's actual commands, dashboards, and access paths without supplied context, and can suggest plausible sounding but detail wise wrong commands.
7. Systematically Updating Runbooks After Every Incident
A runbook that never gets touched again after its creation ages just like any other documentation. A proven process is to specifically check, after every completed postmortem, whether the associated runbook still matches reality, and to involve Claude by presenting it with the new postmortem and the existing runbook together and asking for concrete discrepancies.
Claude is particularly helpful when an incident shows that a diagnostic step described in the runbook no longer worked in practice, for example because a dashboard name changed or a service got renamed. Claude can automatically formulate a concrete change proposal for the runbook as a diff from the postmortem text, which a team member only needs to review and accept instead of rereading the entire document.
8. Maintaining Runbooks as Code in a Git Repository
Teams that maintain runbooks as markdown files in a git repository instead of a separate wiki benefit from letting Claude Code work directly in that repository. After a completed postmortem, Claude Code can be instructed to identify the affected runbook files and submit update proposals as a normal pull request, reviewed by a team member like any other code change before it gets merged.
This workflow has the added benefit of firmly integrating runbook maintenance into the postmortem process that already exists, instead of it being a separate, easily forgotten task. A postmortem template can even include an explicit item asking to update the corresponding runbook with Claude Code before the incident gets marked as closed.
cd runbooks-repo
claude "Read postmortems/2026-08-05-db-pool-exhaustion.md
and check whether runbooks/db-connection-pool-exhausted.md
is still accurate. Propose concrete changes as a diff."
git diff runbooks/db-connection-pool-exhausted.md
git add runbooks/db-connection-pool-exhausted.md
git commit -m "Update runbook after incident 2026-08-05"
9. Limits: Claude Does Not Know Your Internal Access Paths
Claude knows neither the actual internal tool URLs nor the concrete access rights needed for certain diagnostic steps, and cannot provide a reliable assessment of the real impact on your own production system, especially for destructive commands such as a database failover or a cache flush. Every generated runbook therefore needs review by someone with real operational knowledge before it gets used in an actual emergency.
A runbook is also always a support for a human decision, not a replacement for that decision itself. Especially for unusual incidents not covered by any known pattern, the ability of experienced on-call engineers to improvise situationally remains essential, and overly rigid trust in a supposedly complete runbook can even be counterproductive in such cases.
| Runbook section | Purpose | Typical content | Common mistake |
|---|---|---|---|
| Symptom description | Quickly recognizing the right runbook | Observable metrics and user impact | Worded too generally, matches too many incidents |
| First five minutes checklist | Triage under stress without deep diagnosis | Yes/no decisions, set severity | Already contains complex diagnostic steps |
| Most likely causes | Targeted diagnosis instead of guessing | Concrete verification commands per cause | Verification commands outdated or no longer valid |
| Immediate actions | Contain damage before the cause is clear | Activate fallback, reroute traffic | Action with unclear side effects |
| Escalation path | Clear ownership when time runs out | Names, channels, fixed time limits | Vague wording without a concrete time limit |
Mironsoft
AI-assisted development, agent workflows, and team processes
Using Claude or other AI tools on the team, but without a clear workflow?
We set up AI-assisted development workflows for teams, from CLAUDE.md conventions to subagent strategies to code review processes that combine human oversight with AI speed.
Workflow Setup
Cleanly set up CLAUDE.md, project conventions, and tool permissions for the team.
Agent Strategy
Build subagent and automation workflows for recurring development tasks.
Team Onboarding
Train developers in productive, safe use of AI coding assistants.
10. Summary
On-Call Runbooks with Claude: FAQ
Extracting from postmortems
Claude spots recurring patterns across multiple incidents and derives generic runbooks.
First five minutes
Deliberately minimalist triage checklists instead of complex diagnosis under stress.
Escalation paths
Concrete time limits, names, and channels instead of vague wording like 'inform if needed'.
Continuous maintenance
After every postmortem, Claude checks for discrepancies and proposes runbook diffs.