Skip to content
DevOps AI ToolKit
Newsletter
All prompts
Post Mortems with AI Difficulty: Intermediate ClaudeChatGPTCursor

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

More Post Mortems with AI prompts & error guides

Browse every Post Mortems with AI prompt and troubleshooting guide in one place.

Free download · 368-page PDF

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.