How to Rotate an On-Call Schedule Across Time Zones
The goal is follow-the-sun coverage: incidents picked up by whoever is awake, nobody regularly paged at 3am, the 24-hour clock divided without any one person carrying most of the burden.
The hard part isn’t the concept. It’s the handoffs.
The basic model
The simplest structure assigns each regional team a contiguous UTC window during their normal business day:
| Region | Coverage window (UTC) | Local equivalent |
|---|---|---|
| Americas (San Francisco) | 16:00–00:00 UTC | 8am–4pm PST |
| Europe (London) | 08:00–16:00 UTC | 8am–4pm GMT |
| APAC (Singapore) | 00:00–08:00 UTC | 8am–4pm SGT |
24-hour coverage, no one on-call outside working hours. This is the clean version. Real teams don’t always have three balanced regional offices — see below.
Handoffs are the failure point
Most on-call rotation breakdowns happen at handoff boundaries. An incident fires at 15:55 UTC — is that APAC’s or Europe’s? If the answer is ambiguous, pages get dropped or duplicated.
Define it explicitly:
- Ownership is determined by who is on-call at the moment the incident fires, not who first investigated it.
- At shift boundaries, the outgoing engineer writes a brief state summary; the incoming engineer acknowledges before the outgoing goes off-call.
- Build a 15–30 minute overlap at each handoff where both teams are available. It costs little and catches everything that arrives at the seam.
DST causes rotation drift
If your engineers are in DST-observing regions, the UTC coverage windows need to shift when clocks change — or the windows no longer align with people’s actual working days.
Example: London covers 08:00–16:00 UTC in winter. After the UK moves to BST (UTC+1), 08:00 UTC is 9am London — one hour into their day, but they’re effectively starting on-call an hour earlier by local time.
The least error-prone fix: anchor shifts to local time in your on-call tool (“8am–4pm London time”) and let the tool handle the UTC conversion. Most modern platforms support this. If yours doesn’t, you’ll need to update UTC windows twice a year after DST transitions — which people consistently forget to do.
When you don’t have three balanced regions
Three teams with 8-hour windows dividing the clock neatly is a best case. Most teams don’t have that.
Two regions: One must cover the gap. Rotate weekly — week A, Americas extends to midnight UTC; week B, Europe starts at 06:00 UTC. Track it explicitly so neither team carries it indefinitely.
Uneven team sizes: Adjust window boundaries so per-engineer hours are roughly equal, not so regional windows are equal. A team of 10 covering 10 hours is lighter per person than a team of 2 covering 8 hours.
Weekend coverage: Define this separately from weekday. Many teams accept longer SLAs on weekends and fewer on-call engineers. State it explicitly — “implied” weekend coverage expectations are a reliable source of tension.
Use meetwhen to verify that your UTC windows land where you think they do in each engineer’s local time, especially after DST changes or when a new team joins from a different city.
Buy me a coffe