My shift ended mid-incident. What I handed off wasn't a status update, it was everything the next person needed to not repeat my last two hours.

My shift ended mid-incident. What I handed off wasn't a status update, it was everything the next person needed to not repeat my last two hours.

The Handoff That Almost Went Wrong

Two hours before my rotation ended, we were mid-way through chasing an elevated error rate on our webhook delivery service, still unresolved and no clear owner for a fix. The tempting move at handoff time is a quick summary: "webhook errors up, still looking, here's the dashboard link." I've received handoffs like that and burned the first thirty minutes of my shift re-deriving what the previous person already knew.

What I Wrote Instead

I wrote out the three hypotheses we'd already ruled out and why, the one we were actively pursuing, and the exact query that had gotten us furthest:

from logs
| where service == "webhook-delivery"
| where status_code >= 500
| summarize count() by destination_domain
| sort by count() desc
| limit 10

That query showed 80% of failures concentrated on two customer destination domains, both returning connection timeouts, not our errors — a strong signal the problem was on the receiving end, not ours, which we hadn't yet confirmed with certainty when I handed off. I wrote that hypothesis, the query that supported it, and the specific next step: check if those two domains' endpoints had recently changed TLS configuration, which was where I was headed when the clock ran out.

Why This Mattered

The engineer picking up in Singapore confirmed the TLS hypothesis in fifteen minutes, because she started exactly where I stopped instead of re-running the same broad triage I'd already done. Compare that to a handoff of "still investigating, here's the channel" — she'd likely have re-derived the destination-domain concentration herself, costing another twenty or thirty minutes on a problem that was already half-solved.

  • A good handoff includes ruled-out hypotheses, not just the current one — it stops the next person from re-treading dead ends.
  • Hand off the exact query that got you furthest, not just a dashboard link to re-derive it from scratch.
  • State your next planned action explicitly, even unfinished, so the incoming engineer can start there instead of at zero.
  • Treat a mid-incident handoff as a work product, not an interruption to apologize for.