Postmortem On-Call Handoff Quality Analyzer Prompt
Analyze the on-call and shift handoffs that happened during a long-running incident to find where context was lost at the handoff boundary and what handoff artifact would have prevented it.
- Target user
- On-call engineers, SREs, and incident review facilitators
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior SRE who studies how incident context survives (or dies) across on-call and shift handoffs during long-running incidents. You analyze the handoff BOUNDARIES — the moments responsibility transferred — and find where knowledge was dropped, without blaming anyone on either side of the handoff. I will paste: [INCIDENT_TIMELINE] — the full timeline with timestamps. [HANDOFF_EVENTS] — each point where on-call/command/ownership changed hands, who handed off to whom, and what (if anything) was communicated. [HANDOFF_ARTIFACTS] — any handoff notes, chat summaries, runbooks, or tickets used. For each handoff boundary: 1. State when the handoff occurred and what the incident state was at that moment. 2. Reconstruct what the OUTGOING responder knew (hypotheses tried, ruled-out causes, pending actions, mental model of the failure). 3. Identify what of that context reached the INCOMING responder vs. what was lost. 4. Trace any post-handoff rework: repeated diagnosis, re-tried dead ends, reversed actions — evidence that context did not transfer. 5. Specify the exact handoff ARTIFACT (template field, running doc, structured summary) that would have carried the lost context across the boundary. Output format: - Per-handoff findings (time, state, context transferred, context lost, rework caused) - Highest-cost context loss (ranked) - Proposed handoff artifact/template with the specific fields that were missing Guardrails: Stay blameless — context loss is a process and tooling failure, not the fault of a tired responder mid-incident. Mark inferred knowledge or mental models as [ESTIMATE]. Do not assume malice or negligence in a terse handoff. A human validates every reconstruction; you propose artifacts, humans decide adoption.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Long-running incidents fail at the seams. The most expensive minutes are rarely inside a single responder’s shift — they cluster right after a handoff, when the incoming engineer re-runs a diagnosis the previous shift already completed, re-tries a dead end that was already ruled out, or worse, reverses a mitigation because they never learned why it was in place. This prompt targets exactly those boundary moments rather than the incident as a whole, because the handoff is a discrete, analyzable event with a clear before and after. By forcing the model to reconstruct the incident state at the instant of transfer, it makes the boundary the unit of analysis, which is where the recoverable lessons actually live.
The core analytical move is separating what the outgoing responder knew from what the incoming responder received. Most postmortems never do this; they note that a handoff happened and move on. But the gap between those two sets — the tried hypotheses, the ruled-out causes, the pending action that was in flight — is precisely the context that determines whether the incident’s clock keeps ticking or resets. Asking the model to trace post-handoff rework (repeated diagnosis, retried dead ends, reversed actions) gives the analysis hard evidence for context loss rather than speculation: if the new shift spent twenty minutes re-confirming something the old shift already knew, the handoff demonstrably failed to carry it.
Crucially, the prompt ends every finding with a concrete artifact, not a platitude. “Communicate better at handoff” is useless; “the handoff template needs a Ruled-Out Causes field and a Pending Actions field because those are what got dropped” is an action item someone can ship this week. This is the difference between a postmortem that produces a warm feeling and one that produces a durable improvement. Because the model has just enumerated the specific pieces of context that were lost, it is well-positioned to reverse-engineer the template that would have carried them — turning each painful handoff failure into a structural fix that helps every future incident, not just a retrospective sigh.
The blameless framing is non-negotiable here for a human reason: handoffs occur precisely when people are most depleted. The outgoing responder has been fighting a fire for hours and wants to sleep; the incoming one is spinning up cold. A terse or incomplete handoff under those conditions is a predictable outcome of a missing artifact, not evidence that someone was careless. If the review reads as criticism of the tired engineer who wrote a three-line handoff at 4 a.m., the lesson everyone absorbs is to distrust handoffs and hoard context — the opposite of what we want. Marking reconstructed mental models as [ESTIMATE] and validating them with the real responders keeps the analysis both accurate and safe, since guessing wrong about what someone “must have known” can unfairly imply they withheld it.
Related prompts
-
Postmortem Runbook Adherence Checker Prompt
Compare what responders actually did during an incident against the documented runbook for that failure, surfacing where the runbook was skipped, wrong, missing, or out of date so the fix lands on the document and tooling, not the people.
-
Postmortem Escalation and Paging Delay Analyzer Prompt
Analyze how an incident was paged, acknowledged, and escalated to find where alerting and on-call routing added minutes to recovery, so the postmortem fixes the escalation path instead of blaming the responder who was reached last.
-
Postmortem-to-Runbook Generator Prompt
Turn the diagnosis and mitigation steps buried in a one-off postmortem into a reusable, generalized runbook so the next responder to a similar incident recovers in minutes instead of re-deriving everything under pressure.
-
Postmortem Assumptions and Unknowns Extractor Prompt
Read a postmortem draft and surface every unstated assumption and open unknown that is being treated as settled fact, so the root-cause analysis and action items don't quietly rest on unverified claims.
More Post Mortems with AI prompts & error guides
Browse every Post Mortems with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.