On-Call Handoff English: Phrases for Shift Transitions
Learn the vocabulary and phrases for on-call handoffs — verbal and written shift transitions, what to include, what to flag urgently, and handoff templates.
Introduction
The on-call handoff is one of the most operationally critical communication acts in engineering. When you pass responsibility for a production system to a colleague, the information you share — and how clearly you share it — can be the difference between a smooth overnight shift and a missed incident. For non-native English speakers, the challenge is twofold: the vocabulary is highly specialised, and the pressure of a real-time handoff leaves little room for searching for words. This guide gives you the phrases and structure you need to hand off confidently and clearly.
Key Vocabulary Before You Start
Before looking at phrases, it is worth understanding the core vocabulary that appears in every on-call handoff.
Alert and incident terminology:
- An outstanding alert is an alert that has fired and not yet been resolved or acknowledged.
- A pending investigation is an issue that has been identified but whose root cause or resolution is not yet known.
- A known issue is a problem that the team is aware of and has accepted for now, usually with a workaround.
- A workaround is a temporary solution that keeps a system functional while a permanent fix is developed.
Escalation and process terminology:
- The escalation path is the sequence of people to contact if an incident cannot be resolved by the current on-call engineer.
- A runbook is a documented step-by-step procedure for handling a specific type of incident or operational task.
- MTTR (Mean Time to Recovery) is the average time it takes to restore service — useful context when describing incident severity.
The Verbal Handoff
A verbal handoff (in person, on a call, or via a voice message) should be brief but complete. It typically follows a structured format.
Opening — signal the handoff:
- “Handing off to you at 18:00 UTC — let me give you a quick rundown of the current state.”
- “I’m signing off now. Here is what you need to know before I go.”
- “Quick handoff: we had a quiet shift mostly, but there’s one thing to watch.”
Current state summary:
- “Everything is currently green on the dashboards — no active alerts.”
- “There is one open incident: elevated error rates on the payments API, approximately 0.3% of requests. It’s being monitored but is not yet blocking.”
- “We had an alert earlier this afternoon for disk usage on the logging cluster — it’s been acknowledged and the team is working on it, but it hasn’t been resolved yet.”
Active or known issues:
- “Watch out for the memory usage on node-03 — it’s been creeping up since yesterday’s deploy. The workaround is to restart the worker process if it crosses 90%.”
- “There is a known issue with the webhook retry queue — messages are being delivered late but not dropped. The team is investigating tomorrow morning.”
- “The database failover test is scheduled for 22:00 UTC tonight — expect a brief period of elevated latency around that time, but it should be automated and self-correcting.”
Escalation guidance:
- “If the payments error rate goes above 1%, escalate to the platform lead — that’s Priya tonight.”
- “The runbook for the database failover scenario is in Confluence under On-Call Runbooks > Database. It walks you through the manual steps if the automatic failover fails.”
- “If you get an alert from the third-party payment gateway, check the status page first before paging anyone — they often have their own incidents.”
The Written Handoff Summary
A written handoff (in Slack, email, or a handoff document) allows the incoming engineer to review the context at their own pace and refer back to it during the shift.
Standard written structure:
Handoff — [Date] [Time] UTC
Current status: All systems green / One active incident / Two known issues
Open incidents:
- “There is one open incident: elevated 5xx errors on the auth service (Incident #4412, opened at 14:32 UTC). Current impact: approximately 0.5% of login attempts failing. Workaround in place: users can retry successfully. Root cause under investigation by the auth team.”
Known issues to monitor:
- “Watch the memory on app-server-02 — it has been fluctuating since the Tuesday release. No action required unless it exceeds 85%.”
Pending actions:
- “Outstanding: confirm with the database team that the index migration completed successfully — I did not have time to verify before handoff.”
Escalation contacts:
- “Platform on-call tonight: Priya (+44 7xxx xxxxxx)”
- “Database on-call: Marcus (Slack: @marcus.h)”
Shift notes:
- “Deployment of version 3.1.4 is scheduled for 23:00 UTC. The release notes are in the #deployments channel.”
What to Flag Urgently
Not everything needs the same level of emphasis in a handoff. Learn to distinguish between what is informational and what is urgent.
Flag urgently:
- Incidents with active customer impact: “This is affecting users right now — approximately 200 users cannot log in.”
- Issues likely to escalate without action: “If this isn’t resolved in the next two hours, the disk will fill and the logging service will stop writing.”
- Upcoming high-risk events: “There’s a scheduled maintenance window at 02:00 UTC that requires manual confirmation — don’t miss it.”
Flag as informational:
- Resolved incidents with no ongoing risk: “We had a brief spike in latency at 11:00 UTC — it resolved itself within 8 minutes, no action needed.”
- Low-severity known issues: “The dashboard graph for API latency is showing slightly incorrect data — it’s a display bug, the underlying data is fine.”
Key Vocabulary
| Term | Definition |
|---|---|
| outstanding alert | An alert that has fired and has not yet been resolved or dismissed |
| pending investigation | An issue that has been identified but is not yet understood or resolved |
| workaround in place | A temporary measure that keeps the system functioning while a fix is being developed |
| escalation path | The sequence of contacts to notify if an incident cannot be resolved at the current level |
| runbook | A documented procedure for handling a specific operational scenario |
| known issue | A problem the team is aware of and has consciously accepted, usually temporarily |
| handoff | The act of transferring on-call responsibility from one engineer to another |
| shift notes | A written record of events and context from the current on-call shift |
Practice Tips
- Use the formula: status + context + action required. Every item in your handoff should follow this pattern. “Memory on node-03 is elevated (status) — it’s been trending up since Tuesday’s deploy (context) — restart the worker if it crosses 90% (action required).”
- Distinguish “watch” from “act on” items explicitly. Say “this is informational” or “no action needed” for low-priority items, and “this needs your attention” or “flag this if X happens” for active concerns. Do not make the incoming engineer guess which category an item falls into.
- Always include the escalation path. Even if the shift is quiet, the incoming engineer needs to know who to call. This is especially critical for engineers new to on-call rotations.
- Time-stamp everything. When writing a handoff summary, include UTC timestamps for every event. Engineers in different time zones will thank you, and it makes post-incident timelines much easier to reconstruct.
Conclusion
A good on-call handoff is a form of care for your colleague — you are leaving them with the information they need to handle whatever the next hours bring. The vocabulary and phrases in this guide (outstanding alert, workaround in place, escalation path, watch out for) are the building blocks of handoffs that keep systems safe and teams confident. With a consistent structure and clear language, your handoffs will become one of the most trusted communications in your engineering organisation.