🤝 On-Call Handoffs That Don't Restart Diagnosis With AI

The incident outlived my shift. At handoff I dropped a “still working the latency thing, channel has details” into the bridge and logged off, and the next responder did what next responders always do: they scrolled four hundred messages, re-ran two checks I’d already run, and re-tested the cache hypothesis I’d already killed an hour earlier. Twenty minutes of re-diagnosis, all of it redundant, all of it because the state of the investigation lived in my head and a chaotic channel instead of a packet. Handoffs are a quiet MTTR multiplier, and the re-diagnosis tax they impose is almost entirely avoidable.

The fix is a structured handoff: confirmed facts, ruled-out hypotheses, live threads, next action. Assembling that by hand at shift change is itself work nobody wants to do mid-incident — which is exactly why a model that compresses the channel into that structure earns its keep.

The re-diagnosis tax is real and avoidable

When an incident changes hands, value transfers only if context does. Without a packet, the incoming responder rebuilds the picture from raw channel scroll — and crucially, they don’t know what’s already been ruled out, so they re-walk dead ends. That re-walking can cost as much as the original investigation. The cure is the same structure that powers the MTTR funnel elsewhere: organize the state so the next person resumes the search instead of restarting it.

A model reading the channel and your notes can produce that packet in seconds, separating what’s confirmed from what’s guessed — which is the part humans get wrong under fatigue.

Ask for a packet, not a paragraph

The framing forces the high-value sections.

You are writing an on-call handoff packet so the next responder doesn’t re-diagnose. From this channel log and my notes, produce: (1) one-line status — severity, impact, trend; (2) confirmed facts, each with how it was verified — exclude anything not yet checked; (3) ruled-out hypotheses and the evidence that killed them; (4) live threads with owner and what each is waiting on, flag idle ones; (5) the single best next action and any pre-staged mitigation; (6) open questions. Keep confirmed and inferred strictly separate. Never present an unconfirmed hypothesis as a fact.

The output is scannable in under a minute:

Status: SEV2, checkout latency p99 4x, steady (not worsening). Confirmed: DB CPU normal (checked pg_stat_activity); errors started 14:07 (confirmed via metrics); correlated to orders-api v4.2 deploy (rollout history). Ruled out: cache exhaustion (hit ratio 99%); network (cross-AZ latency flat). Live threads: Sam — diffing v4.2 query change, waiting on staging repro. (No update 15 min — possibly idle.) Next action: confirm the new heavy query in pg_stat_statements; rollback of v4.2 is pre-staged, not pulled. Open: does the new query explain the full latency delta, or only part?

The incoming responder skips straight to “confirm the heavy query” instead of re-deriving all of that.

The ruled-out section is the one that saves time

# The incoming responder verifies a "confirmed" fact rather than trusting it
kubectl exec -n orders deploy/pg-primary -- \
  psql -tc "select count(*) from pg_stat_activity;"

# Pick up the live thread exactly where it stalled
kubectl exec -n orders deploy/pg-primary -- psql -tc \
  "select query, total_exec_time from pg_stat_statements \
   order by total_exec_time desc limit 5;"

The ruled-out list is the highest-leverage part of the packet. “Cache exhaustion — killed, hit ratio 99%” stops the next person from spending their first ten minutes re-checking the cache. The fastest investigation is the one that doesn’t repeat work, and a handoff that records dead ends is what makes that possible across a shift boundary.

Keep confirmed and inferred strictly separate

The dangerous handoff failure isn’t omission — it’s laundering a guess into a fact. Under fatigue, “it’s probably the deploy” gets repeated until it sounds settled, and a packet that files it under “confirmed” anchors the incoming responder on an unverified track. So the rule is hard: confirmed facts carry their verification method; inferences are labeled as inferences; nothing crosses that line.

Rules I hold to:

• Every “confirmed” fact names how it was verified. If you can’t say how you know, it’s an open question, not a fact.
• Review the packet for gaps before handing off. The model summarizes only what’s in the channel; a forgotten thread that never got written down won’t appear, so you own completeness.
• Make ruled-out hypotheses visible and durable. They’re as valuable as live threads and they’re what survive the handoff to prevent rework.

You can practice this on the free incident assistant — paste a messy channel and ask for the structured handoff packet, then notice how the ruled-out section changes what the next person does first. The prompt library has a hardened handoff prompt with the confirmed-versus-inferred separation built in.

Handoffs inflate MTTR by making each new responder restart the investigation, and that re-diagnosis tax is recoverable. AI compresses a chaotic channel into a packet that says what’s known, what’s killed, and what’s next — and as long as confirmed never blurs into inferred, the incoming on-call resumes the search instead of running it again.