On-Call Scheduling for Distributed Teams: Timezones, Handoffs, and Follow-the-Sun

The Timezone Problem in On-Call

When your team is in one office, on-call scheduling is straightforward: set up a weekly rotation, pick a handoff time during business hours, and you're done.

When your team spans New York, London, and Bangalore, everything gets complicated. A 9 AM handoff in New York is 2 PM in London and 6:30 PM in Bangalore. A midnight page routes to the engineer in their afternoon, or their early morning, or their deep sleep — depending on which timezone the rotation was configured in.

Distributed on-call scheduling requires timezone awareness at every level: rotation design, handoff timing, escalation policies, quiet hours, and PTO management.

The Follow-the-Sun Model

Follow-the-sun is the gold standard for distributed on-call. Instead of a single engineer being on-call for 24 hours (including their nighttime), on-call responsibility follows the sun — passing between timezone groups so each engineer only covers their business hours.

Here's how it works for a team across three timezones:

Each group covers an 8-hour window during their daytime. No engineer ever gets paged at 3 AM. Everyone sleeps through the night.

When Follow-the-Sun Works

• Team has engineers in at least 2-3 timezone groups
• Each group has at least 2-3 engineers (for rotation within the group)
• The service requires 24/7 coverage
• After-hours incidents are frequent enough to justify the complexity

When It Doesn't Work

• Team is concentrated in one timezone with a few remote engineers
• The service only needs coverage during business hours
• Too few engineers per timezone group to sustain a rotation

For teams that don't have full global coverage, a hybrid model works: follow-the-sun during business hours with a traditional rotation (with quiet hours) for overnight coverage.

Designing Timezone-Aware Rotations

The key to timezone-aware scheduling is treating each timezone group as a separate rotation that feeds into a unified escalation policy.

Step 1: Define Timezone Groups

Group your engineers by timezone proximity. You don't need one group per timezone — group engineers within 2-3 hours of each other:

• APAC: India (IST), Southeast Asia (SGT), Australia (AEST)
• EMEA: UK (GMT/BST), Central Europe (CET/CEST)
• Americas: US East (EST/EDT), US West (PST/PDT), Latin America

Step 2: Set Coverage Windows

Assign each group a coverage window in UTC:

• APAC: 00:00-08:00 UTC
• EMEA: 08:00-16:00 UTC
• Americas: 16:00-00:00 UTC

Adjust for daylight saving time. Some regions observe DST and some don't — your scheduling system needs to handle this automatically.

Step 3: Configure Per-Group Rotations

Within each timezone group, run a standard rotation (weekly or bi-weekly). Each group maintains its own rotation order, and engineers only rotate within their group.

This means:

• An APAC engineer is never scheduled during Americas hours
• An Americas engineer is never scheduled during EMEA hours
• Rotation fairness is calculated within each group, not globally

Clean Handoffs

The handoff between timezone groups is the most fragile part of follow-the-sun scheduling. An incident that occurs during the handoff window can fall through the cracks if neither the outgoing nor the incoming engineer takes ownership.

Handoff Protocol

A reliable handoff process includes:

1. 30-minute overlap: The incoming on-call engineer starts monitoring 30 minutes before the outgoing engineer's shift ends. Both are reachable during this window.

2. Active incidents transfer: Any open incidents are explicitly transferred. The outgoing engineer posts a summary in the incident channel, and the incoming engineer acknowledges.

3. Context handoff: The outgoing engineer shares a brief status update — open incidents, things being watched, recent deployments, anything unusual.

4. Notification routing switch: The scheduling system automatically routes new alerts to the incoming engineer at the designated handoff time.

5. Confirmation: The incoming engineer confirms they're available and have received the context.

Handoff Timing

Avoid handoffs at shift boundaries that feel rushed. Good handoff times:

• During business hours for both groups (the overlap window)
• Not immediately at the start of someone's day
• Not at common meeting times
• Consistent (same time every day, adjusted for DST)

Override Slots for Special Cases

No rotation survives contact with reality without overrides. Common scenarios:

• Engineer has a doctor's appointment during their shift
• Public holiday in one timezone but not others
• Team offsite or conference
• Personal preference swaps between engineers

Overrides should be:

• Easy to create (self-service, not requiring manager approval)
• Time-bounded (override for specific hours, not entire shifts)
• Visible to the team (everyone can see who's actually on-call)
• Auditable (logged for rotation fairness tracking)

PTO Across Timezones

See also: Your On-Call Tool Doesn't Know Who's on PTO — why PTO-aware on-call routing matters even more for distributed teams.

PTO management in distributed teams adds timezone complexity:

• Public holidays vary by country (US Thanksgiving doesn't affect EMEA or APAC)
• PTO days start and end at local midnight, not UTC midnight
• A PTO day in IST overlaps with the previous calendar day in PST

Your scheduling system needs to handle PTO in the engineer's local timezone and adjust the rotation accordingly:

1. Engineer in Bangalore requests Thursday off (IST)
2. System checks their on-call coverage window (00:00-08:00 UTC on Thursday)
3. That window falls on Wednesday evening through Thursday early morning in IST
4. System finds a replacement within the APAC group
5. Override is created for the specific coverage window

The timezone math is error-prone when done manually. This is where integrated PTO and scheduling pays off — the system handles the conversion automatically.

Escalation Policies for Distributed Teams

Escalation policies should be timezone-aware:

• Primary on-call: Current timezone group's on-call engineer
• Secondary on-call: Next timezone group's on-call engineer (they're awake)
• Tertiary: Previous timezone group's on-call engineer (last resort, they might be sleeping)

This means escalation naturally flows to engineers who are awake, rather than waking up someone in the same timezone who might be just as asleep as the primary.

Common Pitfalls

Pitfall: Configuring everything in one timezone. If your scheduling tool stores everything in UTC but displays in the admin's local time, handoff times that look correct to the admin might be wrong for other groups.

Pitfall: Ignoring DST transitions. Twice a year, handoff times shift by an hour for some groups. If your system doesn't handle this, you get a gap (nobody on-call) or an overlap (two people on-call).

Pitfall: Uneven group sizes. If APAC has 2 engineers and Americas has 8, the APAC engineers are on-call far more frequently. Address this by adjusting coverage windows or hiring to balance groups.

Pitfall: No handoff ritual. Without an explicit handoff process, incidents during transitions get dropped. Even a simple Slack message ("I'm on-call now, no open incidents") prevents this.

Making Distributed On-Call Work

OpShift supports timezone-aware scheduling with per-group rotations, automatic PTO integration, override slots, and DST-aware handoff timing. Escalation policies can route to different timezone groups based on time of day.

Flat pricing at $16/month (Basic, up to 100 team members), $39/month for up to 500. Every engineer in every timezone gets full access. Get started at opshift.io.