On-Call Shift Handoff: A Clean Shift-Change Checklist
A sloppy on-call handoff drops context that bites the next shift at 3am. A shift-change checklist and template so nothing important falls through the cracks.
- #incident-response
- #sre
- #on-call
- #handoff
- #reliability
The most dangerous moment in an on-call rotation isn’t the big outage. It’s the handoff — the shift change where one engineer stops watching and another starts, and all the context in the first person’s head is supposed to make it into the second person’s. When that transfer is sloppy, the incoming engineer gets paged at 3 AM for something the outgoing engineer already knew about, already had a workaround for, and simply forgot to mention. The context existed. It just didn’t make the jump.
A clean handoff is a small, boring ritual that prevents a specific and recurring kind of pain. This is the shift-change checklist and template I’ve used to make sure the important stuff crosses the gap every time. It takes five minutes and it saves the next person hours.
What a handoff is actually transferring
A handoff isn’t a status meeting. It’s a transfer of responsibility plus context. The incoming engineer needs to leave the handoff knowing three things: what’s currently on fire or smoldering, what’s fragile and might break, and what they specifically need to keep an eye on. Everything in the checklist serves those three questions.
The failure mode is treating the handoff as “nothing’s broken, you’re good” — because “nothing’s broken right now” hides the flaky service that’s been throwing intermittent errors all afternoon, the deploy that’s going out in an hour, and the customer escalation that’s simmering. Those are exactly what bites the next shift.
The shift-handoff checklist
Copy this into your on-call runbook. The outgoing engineer runs it; the incoming engineer confirms they’ve got each item.
ON-CALL SHIFT HANDOFF
ACTIVE / ONGOING
[ ] Any open incidents? Status, severity, who's engaged, next step.
[ ] Anything degraded but not incident-worthy? (flaky service,
elevated latency, a noisy alert you've been babysitting)
[ ] Any suppressed/silenced alerts? What, why, and when the
silence expires. (Critical — a silence outliving its reason
is how real alerts get missed.)
UPCOMING / SCHEDULED
[ ] Deploys or releases landing during the next shift?
[ ] Maintenance windows, migrations, or scheduled jobs?
[ ] Known risky changes from this shift that might surface later?
WATCH ITEMS
[ ] Systems to keep an eye on and why.
[ ] Customer escalations in progress or expected.
[ ] Anything you tried that didn't work (so they don't repeat it).
LOGISTICS
[ ] Confirm the incoming engineer is actually reachable + paging works.
[ ] Any temporary access, creds, or context they'll need.
[ ] Link to relevant runbooks / recent incident channels.
[ ] Incoming engineer confirms: "Got it, I have the pager."
That last line is the whole point of a handoff, and the one most often skipped: an explicit, verbal-or-written transfer of the pager. Until someone says “I’ve got it,” the responsibility is ambiguous, and ambiguous responsibility at a shift boundary means a page might land on nobody.
The written handoff template
Even with a synchronous handoff chat, write it down. Memory fades and the incoming engineer will want to re-read it at hour six. A lightweight template posted in the on-call channel:
🔄 ON-CALL HANDOFF — [date/time]
Outgoing: [name] → Incoming: [name]
Open/ongoing:
- [e.g. "payments-svc throwing intermittent 500s since 15:00,
~1/hr, not customer-impacting yet, ticket JIRA-123, watching"]
Silenced alerts:
- [e.g. "disk-usage alert on log-host silenced until 09:00 —
cleanup running, re-check if still firing after"]
Upcoming:
- [e.g. "search-svc v2.4 deploy scheduled 22:00, owner @dana"]
Watch:
- [e.g. "customer BigCo escalation open, comms via @sam,
may page if their region degrades"]
Tried & didn't help:
- [e.g. "restarting the worker pool — no effect on the 500s"]
Incoming confirmed: ✅ [name] has the pager as of [time]
The silenced-alert trap
I want to dwell on one line because it causes more preventable 3 AM pages than any other: silenced alerts. During a shift you’ll mute noisy or known-issue alerts to focus. That’s fine — until the silence outlives the reason and either hides a real problem or, worse, expires and dumps a backlog on the next person with no context. Every silence you hand off needs three facts: what’s silenced, why, and when it expires. A handoff that doesn’t account for silenced alerts is a handoff with a hidden landmine.
Common handoff mistakes
- “All quiet, you’re good.” Skips the smoldering stuff that isn’t a full incident yet. Walk the watch items even when nothing’s actively broken.
- No explicit pager transfer. Responsibility stays ambiguous and a page can land on nobody. Always confirm “I’ve got it.”
- Verbal only, nothing written. The incoming engineer can’t re-read a conversation at hour six. Post the written handoff.
- Forgetting silenced alerts. The number-one source of avoidable next-shift pages. Account for every silence.
- Not confirming reachability. Handing off to someone whose pager isn’t actually configured is handing off to a void. Verify paging works.
- Dumping without context. “search is weird” helps no one. Say what’s weird, what you tried, and what you’d check next.
Where AI lightens the handoff
Writing a good handoff summary at the end of a long, tiring shift is exactly when people cut corners, and it’s exactly where AI helps. Point a model at the shift’s incident channels, alert history, and ticket activity and have it draft a handoff summary — what fired, what’s still open, what got silenced and when it expires — for the outgoing engineer to correct and hand over. It catches the “oh, I forgot about that flaky thing at 3 PM” items that a tired human drops. The outgoing engineer still owns the summary and the judgment about what matters; the model just makes sure nothing quietly falls off the list. This is one of the safest, highest-value AI assists in on-call, because the human reviewing it has all the context to catch anything wrong.
Wrapping up
The handoff is a five-minute ritual that decides whether the next shift starts informed or blind. Transfer the pager explicitly, walk the active-upcoming-watch items, account for every silenced alert, and write it down so it survives past the conversation. A team that handles handoffs well doesn’t wake people at 3 AM for problems the last shift already understood — the context makes the jump every time, and that’s the whole job.
AI-drafted handoff summaries are drafts. The outgoing engineer owns what gets handed over.
Related
- Designing a Healthy On-Call Rotation That Doesn’t Burn People Out
- AI-Assisted On-Call Shift Handoff Summaries
- Incident Command Handoff During Long-Running Outages
Get 500 Battle-Tested DevOps AI Prompts — Free
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.