Handovers, Shift Work and On-Call

Why handovers go wrong

IT services run around the clock, but people work in shifts, go on holiday, change teams and go home at five. Every time work moves from one person to another, knowledge can fall through the gap: the half-finished check, the alarm that "is probably fine", the promise made to a user on the phone. The next person does not know what they do not know, so they cannot even ask.

Most of what goes wrong at a handover is not technical. Typical causes:

• Context stays in someone's head. "I already looked at that" means nothing to the next shift unless they know what you looked at and what you found.
• Vague status. "Seems OK now" leaves the receiver to decide whether to watch it, close it or start over.
• No owner for the next step. An open item without a name and a time drifts until a user calls about it.
• Rushed timing. The handover happens in the last two minutes of a tiring shift, by the coffee machine, and nothing is written down.

The fix is boring and effective: a written note in a fixed structure, plus a short conversation in which the receiver can ask questions.

The shift handover

A shift handover is the moment at which responsibility for a team's open work and its systems passes from the outgoing shift to the incoming one, usually as a short written note plus a conversation. In a network operations center (NOC) or a 24/7 service desk it happens two or three times a day; in a day-only team it happens at the start of a holiday or when someone moves on.

Good handovers share a few habits:

1. Prepare it before the end of the shift. Start the note an hour before you leave and add to it as things happen. A note written in the last five minutes is a note written from memory.
2. Use the same structure every time. The reader knows where to look, and the writer is reminded of what to check. The structure below works for most teams.
3. Talk it through. Five minutes on the phone or at the desk catches the questions a note cannot answer. Read the "open" items aloud; the receiver repeats back what they will do first.
4. Link, don't copy. The ticket holds the details; the handover note says what matters about it now and points to the ticket.
5. Stay reachable for a short time. Say how long you can be called with questions, so the receiver does not hesitate to ask.

Writing a handover note

A handover note is a short written summary for the person who takes over your work: the current state, open items with their next step and owner, things to keep an eye on, planned work and any open requests. It is written for someone who was not there and cannot see inside your head.

At 07:00 on Thursday 1 October 2026, Tomasz Nowak finishes a night shift in Kestrel Energy's NOC and hands over to Emeka Obi. This is the note he writes after a long night:

Busy night. Some alarms on the edge router, looked into it,
seems ok now. Billing thing still open, ask Joost.
Check the firewall change.

Every line raises a question. Which router, which alarms, and what does "looked into it" mean? Is the billing item a NOC task? "Check the firewall change": check what, and why? Emeka will spend his first half hour reconstructing the night from tickets and chat history, or he will skip it and be surprised at 09:15. Here is the same night, handed over properly:

NOC handover night → day · Thu 1 Oct 2026 07:00 · Tomasz → Emeka

STATE
All services green except item 1. No major incident open.

OPEN – needs action
1. INC-31877 (P3) Link to carrier B on edge router rt-ams-02 flapped
   6 times between 01:10 and 03:40, stable since. Carrier ticket
   88123 is open; they promised an update by 10:00.
   Next step: chase the carrier at 10:00 if no update.
   If it flaps again: move traffic to carrier A (KB-0414), then call.
2. INC-31880 (P4) Billing export finished at 05:55 instead of about
   02:45 (deadline 06:00).
   Joost Bakker has the details by email and starts on it at 09:00.
   No NOC action.

WATCH
- CHG-7731 firewall rule change ran 23:00–23:20, verified OK.
  If users report VPN problems this morning, suspect this change
  first; the back-out steps are in the change record.

PLANNED TODAY
- 14:00 CHG-7740 switch firmware update in rack B3 (release
  manager: Yara Haddad). NOC watches alarms during the window.

FROM ME
- I promised the billing team an update on INC-31880 "in the
  morning". Joost will send it; nothing for you to do.
- Reachable on my phone until 08:00 for questions.

The second note is longer, but it saves Emeka far more time than it cost Tomasz, and it makes every promise visible. Notice what makes it work:

• Fixed headings (state, open, watch, planned, from me) that are always present, even when a section says "nothing".
• Each open item has a ticket, a current state, a next step, a time and an owner. "Chase the carrier at 10:00" can be done; "keep an eye on it" cannot.
• Conditions are written as if/then, so the receiver knows in advance what to do if the situation changes.
• Promises made to others are handed over too. Users remember what you told them, even when the next shift does not.

For writing good ticket notes in general, see writing tickets and technical documentation.

Handing over during a live incident

Long incidents outlast shifts. Handing over in the middle of one is riskier than a normal handover, because the situation is still changing and people are tired. Three habits help:

• Hand over the role explicitly. Google's site reliability engineering (SRE) book describes how an incident commander hands over with a clear question, "You're now the incident commander, okay?", and waits for a firm yes. Until that answer, the old commander is still in charge. See working under pressure for the incident roles.
• Use the living incident document. If the timeline, the hypotheses already ruled out and the decisions are written down as you go, the handover is mostly "read this, then ask me".
• Announce it. Tell the incident channel who has taken over, so nobody keeps sending questions to someone who has gone to sleep.

Escalating at the right moment

Escalation means moving work to someone with more knowledge (functional escalation) or more authority (hierarchical escalation); the service desk page explains both. The hard part for most starters is not how to escalate but when. People escalate too late because they want to solve it themselves, fear looking incompetent or do not want to wake someone up. The result is a small problem that becomes a long outage.

An escalation path is the agreed, written sequence of people or teams to involve when a problem cannot be solved at the current level or within a set time, with their contact details and the conditions for each step. Because it is agreed in advance, following it is not a personal judgment and not a sign of weakness: it is the procedure.

The automatic part (paging the next person when nobody acknowledges) is set up in the paging tool as an escalation policy; the escalation path also covers when you choose to bring others in.

Signals that it is time

• A time limit has passed. Many teams agree a limit per priority, for example "a P2 you cannot fix in 30 minutes goes to the secondary". Set the timer when you start.
• You are out of good theories. If you are trying things at random, you have stopped troubleshooting; see a structured troubleshooting method.
• The impact is growing: more users, more services, or a deadline (a billing run, a market closing) coming closer.
• The fix needs rights or decisions you do not have: a change to a system you do not own, spending money, telling customers.
• Security or personal data may be involved. Escalate at once; do not investigate alone first. See the help desk's role in incident response.

How to escalate

The person you call, often woken up or pulled out of other work, needs to decide quickly whether and how to help. Give them the facts in one message:

Hi Ravi, portal seems broken?? Can you have a look? Thx

Ravi, escalating INC-31902 (P2) to you as portal tech lead.
Impact: about 30% of portal logins fail with HTTP 500 since 21:40.
Done so far: both web nodes healthy, no deployment today,
token service dashboard green. Error log shows "connection pool
exhausted" on the login service from 21:38.
Need from you: diagnosis of the login service; I don't have
access to its configuration.
I stay on the bridge and keep the ticket and users updated.

The clear version says what is broken, how badly, what is already ruled out, what you need and what you will keep doing. It also shows that escalating does not mean disappearing: you hand over a task, not the incident. For more on asking for help well, see asking good questions and gathering information.

Doing on-call duty well

In an on-call rotation, people take turns being reachable outside working hours to respond to urgent alerts; the ITSM in practice page explains rotations, paging tools and runbooks. This section is about doing the duty itself. How a rotation itself is designed, with primary and secondary, page or ticket, and enough people, is on On-Call.

A call-out is the moment an on-call person is actually called to start work, by a page, phone call or message, as opposed to the hours of only being reachable. In labor law the distinction matters: in the Netherlands (where on-call duty is called consignatie), in the United Kingdom and, for on-call from home, in the United States, being reachable is generally not working time, but the work after a call-out is. The tests differ; see on-call rules below.

Before your on-call week

• Test the pager. Send yourself a test page on the phone you will actually carry, with sound on and do-not-disturb exceptions set.
• Check access while it is quiet. VPN, multi-factor authentication token, admin accounts, laptop charged. Discovering at 03:00 that your password expired turns a ten-minute fix into an hour.
• Read the handover from the previous on-call person and the change schedule for the week: what is fragile, what is planned.
• Know your escalation path and the runbooks for the alerts that fire most.
• Plan your life around it. Stay within reach of your laptop and a network, and within the response time your team has agreed.

When the page comes

1. Acknowledge the page, so the escalation timer stops and others know someone is on it.
2. Assess the impact before you touch anything: who is affected, since when, is it getting worse? Open or link an incident ticket.
3. Follow the runbook if there is one. If there is not, work methodically and write down what you do with timestamps.
4. Escalate by your agreed limits. Do not wait for a perfect picture.
5. Hand over in the morning: a short note in the ticket on what happened, what you did and what still needs daytime attention.

Making on-call sustainable

On-call that wakes people up several times a week is not a personal resilience problem; it is a system problem. A useful rule many teams use: every page should be urgent, need a human, and be something the person can act on. Pages that fail that test lead to alert fatigue (see monitoring and event management), and tired people miss the page that matters.

• Review the pages of every on-call week: which ones could be tuned, automated or moved to office hours? Measuring the load shows such a review.
• Take rest after a night call-out. Start later the next day; it is safer for the systems as well as for you.
• Keep enough people in the rotation, and make swapping shifts easy and normal.
• Speak up early if the load is too high. The health and sustainable work page covers stress and burnout.

On-call rules

The health and sustainable work page covers working hours and night work more broadly.

Checking a roster

Two of the Dutch rules are easy to break by accident when people swap shifts. The script below checks a four-week roster against them (US and UK rules work differently; see above). It is a simplified illustration, not a complete legal check: it treats every "C" day as an on-call day and only counts blocks of free days.

import re
from datetime import date, timedelta

# Four weeks from Monday 2 November 2026, one letter per day:
# W = working day, C = on call (consignatie), F = free (no work, no on call)
START = date(2026, 11, 2)
MAX_ON_CALL_DAYS = 14   # per 4 weeks
MIN_FREE_BLOCKS = 2     # blocks of 2+ days without work or on call


def check(name, roster):
    days = roster.replace(" ", "")
    on_call = days.count("C")
    blocks = [m.start() for m in re.finditer(r"F{2,}", days)]
    print(f"{name}: on call {on_call} days, free blocks {len(blocks)}")
    for i in blocks:
        print(f"  free from {START + timedelta(days=i):%a %d %b}")
    if on_call > MAX_ON_CALL_DAYS:
        print(f"  TOO MANY on-call days (max {MAX_ON_CALL_DAYS})")
    if len(blocks) < MIN_FREE_BLOCKS:
        print(f"  TOO FEW free blocks (min {MIN_FREE_BLOCKS})")


check("Planned", "WWWWWFF CCCCCCC WWWWWFF CCCCCCC")
check("After swap", "WWWWWFF CCCCCCC WWWWWCC CCCCCCC")

Planned: on call 14 days, free blocks 2
  free from Sat 07 Nov
  free from Sat 21 Nov
After swap: on call 16 days, free blocks 1
  free from Sat 07 Nov
  TOO MANY on-call days (max 14)
  TOO FEW free blocks (min 2)

Emeka's planned roster is exactly at the limit. Taking over a colleague's weekend in week three looks like a small favor, but it breaks both rules. Rostering tools usually check this; a quick check before agreeing to a swap does no harm.

Follow-the-sun

Follow-the-sun is a support model in which teams in different time zones hand work to each other at the end of their day, so that work continues around the clock while everyone works during their own daytime. A company with teams in Europe, the Americas and Asia-Pacific can cover 24 hours with three ordinary day shifts and no night shifts.

The price is handovers: three a day, across languages and cultures, often between people who never meet. Everything in this page matters more in a follow-the-sun setup. Teams that make it work usually have:

• one shared ticket system and one handover format, used by every region;
• a short overlap between regions, so at least one live conversation per handover is possible;
• clear rules for which incidents follow the sun and which stay with one owner (a delicate customer conversation is often better kept by the person who started it);
• plain written English, without local abbreviations, because the reader may be working in their second or third language.