It is 3 AM. You are paged for a degraded database. You open your laptop and find zero context — no notes from the previous shift, no indication of what was tried, no idea whether this is a new incident or an ongoing one that the outgoing engineer was already investigating.
You spend 30 minutes reconstructing what happened before you can even begin fixing the problem. Meanwhile, the issue escalates.
This is not a monitoring failure. Your alerting tool worked perfectly — it paged you on time. This is a handover failure. And every on-call tool on the market — PagerDuty, Better Stack, incident.io, Opsgenie — handles alerting. None of them handle what happens when one engineer hands off to the next.
This guide covers how to build a structured on-call handover process that prevents context loss between shifts. It includes a ready-to-use checklist, a handover template, best practices from teams that have solved this, and specific guidance for MSPs running ConnectWise, Autotask, or HaloPSA.
Note: "handover" and "handoff" mean the same thing — handover is more common in UK/global usage, handoff in the US. This guide uses both interchangeably.
70%
of SREs say on-call stress impacts burnout and attrition
Catchpoint SRE Report, 2025
30 min
average time lost to context rebuilding per shift change
Industry average across handover studies
$7,500/mo
potential lost productivity for a 10-person on-call team
Based on 30 min/shift × $75/hr avg engineer rate
What is an on-call handover?
An on-call handover (also called an on-call handoff) is the structured transfer of operational context from an outgoing on-call engineer to the incoming one. It covers active incidents, pending items, temporary workarounds, system warnings, and anything the incoming engineer needs to know before they are responsible for responding to alerts.
A good handover is nota Slack message saying "all clear." It is not a verbal "it was a quiet week." It is a documented, structured brief that the incoming engineer reads, acknowledges, and can reference at 3 AM when they get paged for something the outgoing engineer was already tracking.
The concept is not new. Healthcare has used structured handover frameworks like SBAR (Situation, Background, Assessment, Recommendation) for decades — and studies show it reduced handover time from 45 minutes to 7 minutes while improving patient safety. On-call engineering teams face the same knowledge transfer challenge, but most have no equivalent structured process.
Why on-call handoffs fail
Most on-call teams do not have a handover problem because they have bad engineers. They have a handover problem because they have no process. Here are the five failure modes we see most often:
The assumption gap
The outgoing engineer assumes the incoming engineer can see the ongoing investigation in Slack. The incoming engineer assumes that if something were critical, it would have been explicitly mentioned. Neither realises an active problem is progressing without oversight until it escalates.
Invisible workarounds
Engineers under pressure implement temporary fixes — restarting a service, clearing a cache, disabling a feature flag. Without handoff documentation, incoming engineers do not know these stopgap measures exist. The service appears healthy while running on duct tape that could fail at any moment.
No incentive to document
As one Hacker News commenter put it: "The issue is there is no incentive for the person leaving to make these handovers." The outgoing engineer is mentally done with their shift. The effort of documenting feels like unpaid overtime. Without enforcement, handover quality decays to zero within weeks.
Verbal handoffs decay instantly
A verbal "it was a quiet week" tells the incoming engineer nothing actionable. It is not a handoff — it is an invitation to rediscover everything the outgoing engineer already knew. Within hours, the details of that verbal summary are forgotten by both parties.
Cross-shift problem duplication
Without structured handovers, teams solve the same problems across different shifts. An intermittent issue investigated by the night shift gets re-investigated from scratch by the morning shift — doubling the engineering time spent and delaying resolution.
The cost of bad on-call handovers
Context loss is not just an inconvenience. It has measurable financial and operational impact.
Time cost
If each shift change costs 30 minutes of context rebuilding, a team with 2 daily handovers loses 365 engineering hours per year. At $75/hour, that is $27,375/year in wasted productivity — for a single rotation.
Incident cost
Extended MTTR when the incoming engineer lacks context. A 15-minute incident becomes a 45-minute incident because the first 30 minutes were spent figuring out what was already known.
Burnout cost
Nearly 70% of SREs say on-call stress impacts burnout and attrition. Bad handovers amplify this — an engineer who starts every shift blind dreads on-call more than one who starts informed.
Replacing a burned-out engineer costs $50,000–$200,000 in recruiting, onboarding, and ramp-up time.
Client cost (MSPs)
When a technician changes shift without context, the client feels it. They re-explain their issue. They wait while the new tech catches up. This is lost revenue and lost trust — directly impacting NPS and contract renewals.
On-call handover best practices
These eight practices are drawn from teams that have solved the handover problem — including GitLab's public handbook, the Google SRE Workbook, and our own experience building Shiftctl.
1. Enforce written sign-offs
Do not let engineers end shifts without documenting what happened. If the handover is optional, it will be skipped. If it is enforced — the shift does not officially end until the sign-off is submitted — it becomes habit within a week.
2. Use a consistent template
Same fields every time: incidents handled, pending items, workarounds, warnings, difficulty rating. A template removes the cognitive load of deciding what to include. See the template section below.
3. Schedule overlap windows
A 15–30 minute synchronous overlap between outgoing and incoming engineers allows for questions, clarification, and live context transfer. During active incidents, extend this to 60 minutes.
The outgoing engineer should not disappear before the incoming one is confident.
4. Pick one handoff time for the whole team
Somewhere between 9 AM and 11 AM works well — it gives the incoming engineer time to settle in rather than jumping straight on to alerts.
Avoid Friday handoffs — if details are missed, the new on-call cannot ask the old on-call until Monday.
5. Include difficulty ratings
Have the outgoing engineer rate shift difficulty on a 1–5 scale. Over time, this data reveals burden imbalances — one engineer consistently getting the hard shifts — that managers can address before they cause burnout.
6. Require acknowledgement
The incoming engineer must confirm receipt of the handover brief. "It was sent" is not the same as "it was read."
A timestamped acknowledgement ensures the incoming engineer has actually reviewed the brief before taking responsibility.
7. Automate what you can
Auto-pull open incidents from your alerting tool. Auto-attach pending tickets. Auto-notify the incoming engineer via Slack or Teams. The less manual work the handover requires, the more likely it is to actually happen.
8. Review handover quality monthly
Track metrics like completion rate, acknowledgement time, and post-handover MTTR. If handover quality drops, catch it early — before it causes an incident. See the metrics section below.
On-call handoff checklist
Two checklists — one for the outgoing engineer completing their shift, one for the incoming engineer starting theirs. These cover the on-call sign-off process end-to-end.
Outgoing engineer — shift sign-off
- Document all incidents handled (severity, status, actions taken)
- List pending or unresolved items with context and next steps
- Note any temporary workarounds currently in place
- Flag warnings or things to watch (degraded services, flaky alerts)
- Rate shift difficulty (1–5 scale)
- Add notes on unusual system behaviour or anomalies observed
- Submit the handover brief
- Confirm the incoming engineer received and acknowledged it
Incoming engineer — shift start
- Read the handover brief before starting the shift
- Acknowledge receipt (timestamped confirmation)
- Review open incidents and their current status
- Check for temporary workarounds that may need attention or rollback
- Verify monitoring dashboards are accessible and showing current data
- Confirm escalation contacts are current for your shift window
- Note any questions for the outgoing engineer (ask during overlap window)
On-call handover template
Use this template as-is or adapt it to your team. The key is consistency — every shift produces the same fields so the incoming engineer always knows where to find information.
Automating on-call handovers
Templates are a good start. But manual templates fail over time. People skip fields. New team members do not know the template exists. The shared Google Doc fills up and nobody creates a new one. Compliance decays silently until an incident exposes the gap.
What automation should handle:
- Auto-pull open incidents from your alerting tool (PagerDuty, Better Stack, etc.) into the handover form, so the outgoing engineer does not have to copy-paste them manually.
- Enforce completion before the shift officially ends. The handover is not optional — it is a gate. The shift does not close until the sign-off is submitted.
- Deliver the brief automatically to the incoming engineer via Slack, Microsoft Teams, or email — wherever they will actually see it.
- Require timestamped acknowledgement from the incoming engineer, creating a verifiable record that the handover was received and read.
- Store an audit trail for compliance — every handover, every sign-off, every acknowledgement, timestamped and searchable.
Some teams build custom Slack bots (Lambda + PagerDuty API) to handle parts of this. GitLab uses internal Slack commands to auto-create handover issues. But these are fragile, team-specific solutions that break when the engineer who built them leaves.
Shiftctl is purpose-built for this. It handles enforced sign-offs, structured handover briefs, automatic notifications, acknowledgement tracking, and audit trails out of the box — without requiring your team to build or maintain custom tooling. It works alongside whatever alerting tool you already use (PagerDuty, Better Stack, incident.io) via iCal schedule sync.
On-call handovers for MSPs
If you run a managed service provider, on-call handovers are harder than they are for SaaS engineering teams — and the stakes are higher.
Why MSPs have it worse
Multiple customers = multiplied context. A SaaS team hands over context for one product. An MSP technician hands over context for 20, 50, or 100 clients — each with different environments, SLAs, and escalation paths.
Your PSA is the source of truth. Your billing, SLAs, and customer communication flow through ConnectWise Manage, Autotask PSA, or HaloPSA. An on-call tool that cannot sync tickets to your PSA creates double-entry and missed tickets.
Client experience degrades at every shift change. When a technician finishes their shift and the next tech starts without context, the client feels it. They re-explain their issue. They wait while the new tech catches up. This directly impacts customer satisfaction and contract renewals.
You bill for on-call time. If your handover process costs each technician 30 minutes of unbillable context reconstruction per shift, that is real money — $500–$7,500/month in lost billable revenue, depending on your rate and team size.
What MSPs need from an on-call handover tool
PSA ticket sync. Tickets logged during a shift should automatically appear in ConnectWise, Autotask, or HaloPSA — no copy-pasting between tools, no missed tickets.
Per-client context in handovers.The handover brief should organise information by client, not just by incident. The incoming technician needs to know "Client X has an ongoing issue" — not just "there is an ongoing issue."
Compliance documentation. For SLA reporting, audit requirements (SOC 2, ISO 27001, ITIL), and dispute resolution, you need timestamped records of who was on-call, what was handed over, and when it was acknowledged.
Every on-call tool on the market — PagerDuty, Better Stack, incident.io, Squadcast — is built for SaaS engineering teams. None of them offer PSA integrations or structured handovers designed for MSPs. Shiftctl is the only on-call tool with direct integrations to ConnectWise Manage, Autotask PSA, and HaloPSA — and it is built specifically around the handover problem that MSPs face at every shift change.
For a broader comparison of on-call tools and where Shiftctl fits, see our guide to PagerDuty alternatives in 2026.
Measuring handover quality
You cannot improve what you do not measure. These six metrics tell you whether your on-call handover process is working — or silently degrading.
Handover completion rate
What percentage of shifts end with a completed sign-off? If this drops below 90%, your process has a compliance problem.
Acknowledgement time
How quickly does the incoming engineer confirm receipt of the handover brief? Long gaps mean they are starting shifts blind.
Post-handoff MTTR
Does mean-time-to-resolution spike after shift changes? If incidents that start within 60 minutes of a handoff take longer to resolve, your handovers are not transferring enough context.
Repeat incidents across shifts
Are teams investigating the same issue twice because the incoming engineer did not know the outgoing one already looked at it? This is the clearest signal of context loss.
Difficulty distribution
Are shift difficulty ratings evenly distributed across engineers? Persistent imbalances lead to burnout for the engineers who consistently draw the hard shifts.
Handover skip rate
How often do engineers skip the handover entirely — ending their shift without submitting a sign-off? With enforced sign-offs, this metric should be zero.
Shiftctl's analytics dashboard tracks these metrics automatically, including difficulty trends, burden distribution across engineers, and acknowledgement time histograms. Managers can generate PDF reports for leadership reviews and compliance audits.
Frequently asked questions
What should be included in an on-call handover?
A complete on-call handover should include: all incidents handled during the shift (severity, status, actions taken), pending or unresolved items with context, temporary workarounds currently in place, warnings or watch items, a difficulty rating, system state summary, and a formal sign-off from the outgoing engineer. The incoming engineer should acknowledge receipt before starting their shift.
How long should an on-call handoff take?
The written handover brief should take 5–10 minutes to complete. If your team includes a synchronous overlap window (recommended), schedule 15–30 minutes for the outgoing and incoming engineers to discuss. During active incidents, extend this to 60 minutes to ensure full context transfer.
What is the difference between a handover and a handoff?
They mean the same thing. "Handover" is more common in British English and global usage. "Handoff" is more common in American English. In the context of on-call engineering, both refer to the structured transfer of operational context from one on-call engineer to the next.
How do you prevent context loss during shift changes?
Four mechanisms work together: (1) enforced sign-offs that require the outgoing engineer to document shift state before leaving, (2) structured templates that ensure consistent information capture, (3) required acknowledgement from the incoming engineer confirming they read the brief, and (4) automation that pulls open incidents and pending items into the handover form automatically.
What is an on-call sign-off?
An on-call sign-off is a formal confirmation that the outgoing engineer has documented the current state of their shift — incidents, pending items, workarounds, and warnings — before ending their on-call period. In tools like Shiftctl, sign-offs are enforced: the shift cannot be completed without submitting the handover documentation.
Do MSPs need a formal on-call handover process?
Yes — arguably more than SaaS engineering teams. MSPs manage multiple clients, each with different environments and SLAs. Without structured handovers, technicians lose client context at every shift change, leading to repeated troubleshooting, SLA breaches, and degraded customer experience. MSPs also need handover data flowing into their PSA (ConnectWise, Autotask, HaloPSA) for accurate billing and compliance reporting.
Can I automate on-call handovers?
Yes. Tools like Shiftctl automate the handover process by enforcing sign-off fields at shift end, auto-delivering structured briefs to the incoming engineer via Slack or Teams, requiring timestamped acknowledgement, and storing a full audit trail. This replaces manual templates, shared documents, and custom Slack bots with a purpose-built workflow.
See it in action
This is what a structured handover looks like in Shiftctl — the incoming engineer gets a complete brief before starting their shift.
Stop losing context between shifts
Shiftctl adds enforced sign-offs, structured handover briefs, and PSA ticket sync to your on-call process. Works alongside PagerDuty, Better Stack, or whatever alerting tool you already use. Free for 2 users. No credit card required.