Postmortem Runbook Adherence Checker Prompt

You are a senior SRE conducting a blameless comparison between a documented runbook and what actually happened during an incident. Every divergence is a signal about the runbook or tooling, never a judgment of the responder.

I will paste:
[RUNBOOK] — the documented procedure for this failure class.
[INCIDENT_TIMELINE] — what responders actually observed and did, with timestamps.
[CONTEXT] — anything about tooling, access, or conditions during the incident.

Do this:

1. Build a STEP MAP: for each runbook step, state what the timeline shows happened against it, and classify as FOLLOWED, SKIPPED, DEVIATED, or NO EVIDENCE.
2. For every SKIPPED or DEVIATED step, diagnose the runbook/tooling deficit: was the step unclear, wrong for this variant, blocked by missing access, slower than an ad-hoc action, or simply undiscoverable under pressure? Frame it as a document or system gap.
3. Flag RUNBOOK-MISSING actions: things responders did that worked but the runbook never mentioned, which should be added.
4. Flag STALE steps: instructions referencing tools, hostnames, or states that no longer match reality.
5. Produce prioritized RUNBOOK FIXES: specific edits, additions, or deletions, ordered by how much they would speed the next response.

Output as Markdown with a step-map table plus the four lists above. Stay strictly blameless: describe what the runbook or tooling failed to provide, never what a person failed to do. Mark any inference not directly supported by the timeline as [ESTIMATE]. A human runbook owner decides which fixes to accept; you only propose them.

Why this prompt works

The most common way a runbook fails is quietly: it exists, it looks authoritative, and during the incident nobody used it because it was three tools out of date, gated behind access the on-call didn’t have, or written for a variant of the failure that didn’t happen. A postmortem review that only reads the timeline misses this entirely, because the timeline records what people did, not what the document promised. This prompt forces a side-by-side comparison so the gap between the written procedure and reality becomes visible and actionable, which is where most durable response improvements actually come from.

The classification scheme is the heart of the design. By tagging each step FOLLOWED, SKIPPED, DEVIATED, or NO EVIDENCE, the analysis avoids the trap of treating any departure from the script as a failure. A DEVIATED step where the responder did something smarter than the runbook is a runbook bug, not an operator error; a SKIPPED step might mean the step was redundant or undiscoverable. The RUNBOOK-MISSING and STALE categories capture the two other silent killers: institutional knowledge that lives only in senior engineers’ heads, and documentation rot that makes the whole runbook feel untrustworthy. Naming these explicitly keeps the model from collapsing everything into a single vague “the runbook could be improved.”

The blameless framing here is not decoration; it is what makes the tool safe to use at all. The instant a runbook-adherence review starts reading as “here is where you didn’t follow procedure,” on-call engineers will stop being candid in timelines, and the timelines are the only raw material this analysis has. By requiring every finding to be phrased as a document or tooling deficit, the prompt keeps the conversation on the artifacts you can actually change. The NO EVIDENCE default and the [ESTIMATE] markers guard against the model manufacturing certainty from a sparse timeline, which would produce false “skipped step” findings that unfairly implicate responders.

Keeping the human runbook owner as the decision-maker matters because a runbook edit proposed against a redacted, secondhand account can easily be wrong for the live system. The prompt’s job is to surface candidate gaps and draft fixes quickly; validating them against the real tooling, access model, and current architecture is work only someone with production context can responsibly do.