Best on-call scheduling for follow-the-sun teams?

For a follow-the-sun engineering/SRE team, I’d recommend a 3-region, business-hours-first schedule with a local primary + local secondary, rather than a single global rotation.

Recommended model

The exact hours should overlap slightly—30–60 minutes is ideal—so the outgoing and incoming engineers can hand off active incidents. Follow-the-sun schedules are specifically intended to avoid waking engineers during their local nighttime hours.

The setup I'd use

• Primary: one engineer in the region currently in daylight/business hours.
• Secondary: another engineer in the same region, paged only if the primary doesn't acknowledge.
• Global emergency fallback: a senior engineer/team that gets paged only for truly critical incidents.
• Handoff: 15–30 minutes of overlap with a written handoff containing active incidents, risks, and unusual system conditions.
• Rotation length: usually 1 week per person for low/medium alert volume; shorter rotations if the service is particularly noisy. Weekly rotations are a common fit for teams of three or more.
• No overnight paging: suppress or defer non-critical alerts until the responsible region comes online.
• Overrides: vacations, holidays, and swaps should modify the schedule rather than changing the underlying rotation.

One important nuance

Don't make "follow the sun" mean every alert gets handed to the next region. For a P1 incident, keep ownership with the engineer/team that understands the system until there's a deliberate handoff. Otherwise, you can create a relay race where every timezone spends the first 20 minutes rediscovering the incident.

A better rule is:

The sun follows the incident, not just the clock. For example, if EMEA inherits a P1 from APAC, EMEA owns it, while APAC remains available for context until the handoff is complete.

Tooling

Both support.pagerduty.com and atlassian.com explicitly support follow-the-sun configurations, multiple rotations, overrides, and escalation policies. PagerDuty's current scheduling system even includes a Follow the Sun template.

My default recommendation: weekly rotation + 3 regional daylight shifts + local secondary + 30-minute handoff overlap + severity-based overnight escalation. It's usually the best balance between coverage, fairness, and keeping people genuinely off-call when they're off-call.

If you tell me your team's locations/time zones and number of engineers, I can lay out an actual 24/7 schedule (including weekends and holidays).

Designing an on-call schedule for a follow-the-sun (FTS) team requires balancing continuous global coverage with engineer well-being, clean handoffs, and localized holiday handling. When spanning three major regions (e.g., Americas, APAC, and EMEA), a poorly structured rotation can lead to communication gaps and severe burnout.

The most effective strategies, structures, and best practices for organizing a global follow-the-sun on-call rotation include:

1. The Core Regional Hand-Off Model (8-Hour Local Shifts)

Instead of having individuals stretch across odd hours, align on-call ownership with local working hours in each major hub.

• Local Ownership: Each regional hub (e.g., APAC handles daytime alerts, passing to EMEA, then to the Americas) takes ownership of the primary pager during their local working hours (typically 8:00 AM to 5:00 PM local time).
• No Overnight Shifts: The primary goal of a true FTS model is that no one carries the pager overnight . Local engineers log off at the end of their regional shift, meaning local rest is preserved.

2. The 15 to 30-Minute Overlap & Handoff

A staggering amount of context is lost in global handoffs if it’s purely asynchronous.

• Synchronous Sync: Schedule a mandatory 15–30 minute overlap window between outgoing and incoming regional teams.
• Handoff Checklist: Use this time to verbally review ongoing low-priority investigations, flaky tests, unresolved customer tickets, or active deployments. Platforms like PagerDuty On-Call Management or Opsgenie can manage rotation handoffs, but the human-to-human context transfer is what prevents dropped balls.

3. Standardize Global Escalation and Tooling

• Unified Severity Levels: Ensure that a "Sev-1" means the exact same thing in Tokyo, London, and San Francisco. Ambiguity in severity causes hesitation or over-escalation.
• Centralized Runbooks: Keep living documentation (playbooks, architecture diagrams, recent changes) in a unified, easily searchable workspace (like Confluence or Notion) rather than localized regional wikis.
• Automated Alert Routing: Configure your alerting tool to automatically route incoming pages to the active geographic schedule based on UTC time blocks, eliminating manual toggle errors.

4. Accounting for Regional Holidays and Time-Zone Gaps

• Holiday Swaps: Regional teams have different local holidays (e.g., Diwali in India, Thanksgiving in the US, Golden Week in Japan). Build a cross-region buddy system where an EMEA or Americas engineer covers an APAC holiday, with reciprocal payback later.
• The "Coverage Gap" Fallback: If you only have two regions instead of three (leaving an 8-hour gap), do not force a middle-of-the-night shift. Instead, use a "follow-the-sun-plus-on-call-support" model where the twilight hours are backed by a secondary passive/secondary rotation on-call from the adjacent waking region.

If you want to tailor this further, tell me:

• How many distinct time zones or regional hubs do you have?
• What alerting/on-call tool are you currently using (e.g., PagerDuty, Opsgenie, Grafana OnCall)?

I can help design a specific rotation template or handoff checklist for your team.

For a genuinely global team, I’d use a Follow-the-Sun + local primary/secondary model rather than one 24/7 rotation.

Recommended setup

The exact handoff times should follow your teams’ normal working hours, rather than forcing everyone into arbitrary UTC blocks. Follow-the-sun is specifically intended to keep on-call during daylight/business hours and avoid overnight pages.

The key design choices

• Primary + secondary within each region. The primary handles the incident; the secondary is automatically paged if there's no acknowledgment after, say, 5–10 minutes. Escalation policies are important because follow-the-sun doesn't eliminate individual failures to respond.
• Overlap shifts by 30–60 minutes. Have the outgoing and incoming engineers overlap for handoff, especially for active incidents.
• Don't rotate across regions every week. Keep engineers attached to their local region and rotate within that region. This makes sleep schedules predictable.
• Use a short, predictable regional rotation. For example, one week primary / one week secondary, or daily primary rotation if the team is large enough. Daily, weekly, and custom rotations are all supported by common on-call tooling.
• Separate P1 from everything else. A regional team should own normal incidents during its daylight window. For a truly critical P1 that cannot wait, have an escalation path to a global backup.
• Use overrides for vacations and swaps, rather than modifying the recurring schedule.
• Measure burden, not just coverage: pages/person, nighttime pages, acknowledgment time, escalation rate, and incidents per engineer.

A concrete example

Suppose you have engineers in San Francisco, London, and Singapore:

Singapore → London → San Francisco → Singapore

Each region takes responsibility during its normal working day. At the handoff, the incoming engineer gets a concise status of active incidents and unresolved risks. AWS explicitly supports consecutive rotations for this kind of follow-the-sun arrangement.

I'd also keep a global emergency backup who is not paged for ordinary alerts—only for high-severity incidents that the regional team cannot resolve. This prevents the "follow the sun" model from quietly turning back into 24/7 on-call.

My default recommendation: 8–9 hour regional shifts + 30–60 min overlap + primary/secondary per region + automated escalation + global P1-only backup.

If you tell me your team locations, number of engineers per region, and required coverage (e.g. 24/7 or business-hours), I can lay out an actual weekly rotation that minimizes overnight work and keeps the load fair.

Running a true follow-the-sun (FTS) on-call model means passing the operational baton smoothly across global regional hubs (e.g., APAC → EMEA → Americas) so that everyone works local daytime hours.

The best on-call scheduling strategies and practices for distributed teams focus on eliminating handoff drops, respecting regional nuances, and keeping engineering burnout low.

Core Structural Models

1. The 8-Hour Regional Shift (The Pure Play)
   • How it works: Each regional hub (e.g., Singapore/Sydney, London/Dublin, and US East/West) takes responsibility for an 8-hour block corresponding to their local working day.
   • Best for: Mature, evenly-staffed global teams across 3 primary time zones.
   • The Catch: Requires strict synchronization at the 8-hour boundary.
2. The 12-Hour Overlap Rotation (The Safety Net)
   • How it works: Regions work 12-hour shifts that feature a 2-to-4-hour overlap window with the adjacent region.
   • Best for: Teams with higher incident volumes or complex systems where context transfer takes time.
   • Advantage: The incoming engineer is already online and briefed before the outgoing engineer logs off.
3. Follow-the-Sun + Follow-the-Moon Hybrid
   • How it works: Standard daytime hours are covered locally, but the night shift isn't passed around globally if one region is understaffed. Instead, night coverage rolls to a designated secondary region or uses a "follow-the-moon" secondary backup.

Best Practices for FTS Success

• Standardize a 15-Minute Sync Handoff: Never rely purely on asynchronous ticket notes. A quick 15-minute Slack/video handoff or a structured handoff document between the outgoing and incoming regional engineer prevents alerts from falling into a black hole.
• Account for Regional Holidays Globally: Local holidays (e.g., Diwali in India, Thanksgiving in the US, Golden Week in Japan) mean regional staffing levels fluctuate. Your scheduling tool must allow cross-region coverage swaps easily without breaking primary rotations.
• Automate Coverage-Gap Detection: Use an on-call management platform that explicitly validates time-zone boundaries so that a gap in the schedule triggers an alert before a shift starts, rather than during an outage.
• Define Global Escalation Paths: If a region experiences a catastrophic incident that outlasts their 8-hour shift, establish whether the engineer stays on to see it through (incident owner continuity) or hands it over mid-incident to the fresh incoming region.

Top Tools to Manage FTS Schedules

• PagerDuty: Excellent for multi-region schedules, follow-the-sun routing rules, and automated handoffs across different time zones.
• Opsgenie (by Jira Service Management): Strong time-zone support, flexible rotation rules, and seamless escalation integration.
• Grafana OnCall / Better Stack: Modern alternatives offering great calendar sync, straightforward UI, and robust alerting configurations.

If you'd like to tailor this further, let me know:

• How many distinct time zones or regional hubs you are working with
• Roughly how many engineers are eligible for the rotation
• What tooling (if any) you are currently using

I can help you design a specific shift calendar layout or handoff template.

Implementing a Follow-the-Sun (FTS) on-call schedule is the gold standard for global engineering and support organizations. By passing the pager across geographical regions as the workday ends, you eliminate brutal overnight shifts and maintain continuous 24/7 responsiveness.

An optimized Follow-the-Sun on-call scheduling framework relies on specific structural blueprints, tooling, and operational habits:

1. Optimal Time-Zone Configuration (The 3-Site Sweet Spot)

• The 3-Region Model (Ideal): Distribute your team across the Americas (e.g., US/Canada), Europe/Middle East/Africa (EMEA), and Asia-Pacific (APAC). Spacing regions roughly 8 hours apart creates a natural handoff that maps perfectly to local business hours.
• The 2-Region Model (Minimum Viable): If you only have two regions (e.g., North America and India/APAC with a 9–12 hour difference), you will have an overlap gap. Cover these gaps with a brief 2–3 hour shared window or a localized "extended day" shift rather than forcing full night coverage.

2. Shift Structuring & Overlap Windows

• Local Business Hours Alignment: Structure shifts to match local working hours (e.g., 9:00 AM to 5:00 PM local time) rather than rigid 6-hour artificial blocks, which often spill into personal time.
• The 30-to-60 Minute Handoff Overlap: Always design a mandatory overlap window where both the incoming and outgoing regional engineers are logged on simultaneously. Use this window for a live or asynchronous sync on active issues, unstable metrics, or recent deployments.

3. Tooling and Infrastructure

• Automated Scheduling Engines: Use enterprise incident platforms like PagerDuty or Atlassian Jira Service Management to build multi-layered, time-zone-aware schedules. Configure the tool to automatically transition the primary on-call tag as the clock strikes the handoff hour.
• Collaboration-Native Routing: For tighter, chat-ops-driven coordination, tools like incident.io integrate on-call schedules and incident response directly inside Slack or Microsoft Teams, reducing the "coordination tax" of spinning up bridges during handoffs.

4. Essential FTS Best Practices

• Single Source of Truth for Runbooks: Global fragmentation kills FTS efficiency. Ensure all regions use identical monitoring tags, severity definitions, and up-to-date runbooks stored in a centralized, easily searchable wiki.
• Asynchronous Handoff Artifacts: Do not rely on expensive cross-timezone meetings for every shift change. Mandate a structured handoff ticket, Slack/Teams thread summary, or a quick screen recording detailing active alerts, ongoing investigations, and "watch items" before the outgoing engineer signs off.
• Enforce Incident Load Caps: Follow-the-sun fails if one region is a "hot spot" plagued by noisy, un-tuned alerts. Keep actionable alerts to Google's recommended maximum of 2–3 per shift; if a region exceeds this, pause the rotation to fix the alerting stack rather than burning out engineers.

To help tailor this specifically to your setup, tell me:

• What geographic regions or time zones is your team currently spread across?
• What primary tooling (PagerDuty, Jira, Opsgenie, Slack) are you using for incident management?

For a follow-the-sun engineering/SRE team, I’d optimize for regional handoffs rather than a single 24/7 rotation.

Recommended model

The key is to make each region responsible during its normal working hours, so nobody routinely gets paged overnight. Atlassian explicitly describes follow-the-sun scheduling as a model for geographically distributed teams that avoids waking people in the middle of the night.

Best tooling options

1. Atlassian Opsgenie / Jira Service Management — best if you're already in the Atlassian ecosystem

It supports multiple rotations restricted to particular days/times, custom rotation lengths, routing rules, escalation policies, and schedule overrides—all useful for regional coverage.

One important 2026 consideration: Atlassian is migrating Opsgenie capabilities into Jira Service Management, with existing Opsgenie configurations scheduled for migration before April 5, 2027.

2. PagerDuty — best general-purpose choice for mature SRE organizations

I'd favor it when you need sophisticated incident response, service ownership, escalation chains, schedules, and integrations across a large organization.

3. A lightweight calendar + alerting system — best for small teams

If you only have a handful of services and predictable regional coverage, you can keep the schedule relatively simple, but I'd still want automated paging and escalation rather than relying on a shared calendar.

The schedule I'd actually use

Rather than:

Person A → Person B → Person C → Person A, 24 hours each

use:

APAC team → EMEA team → Americas team → APAC team

with each team's internal rotation handling vacations and individual workload.

Then add one escalation path across regions. For example:

Americas primary → Americas backup → EMEA lead → global incident commander

That gives you redundancy without making the next region responsible for every incident.

A good system should also support overrides/swaps, because vacations and unexpected absences are inevitable. Opsgenie, for example, supports ad-hoc schedule overrides without modifying the underlying rotation.

My pick

If you're starting from scratch:

PagerDuty → strongest all-around choice for a serious SRE/on-call program.

Jira Service Management/Opsgenie → especially attractive if your organization already runs heavily on Jira/Atlassian.

The bigger decision, though, is schedule design, not the tool: use regional business-hour ownership, a short handoff overlap, explicit escalation to another region, and a single source of truth for who owns an incident.

For a true follow-the-sun team, I’d recommend regional primary + secondary rotations, with handoffs during overlapping working hours rather than a global 24-hour rotation.

A strong default

The exact UTC boundaries should follow your teams' actual working hours. The key principle is that each region owns incidents during its daytime, so nobody routinely gets paged at 2 a.m. Follow-the-sun scheduling is specifically recommended for reducing overnight disruption and burnout.

The part I'd optimize most: handoffs

Have a 30–60 minute overlap between regions. During the overlap:

1. Incoming engineer reviews active incidents.
2. Outgoing engineer gives a short verbal/written handoff.
3. Any unresolved P1/P2 gets an explicit owner.
4. The outgoing engineer stays available until the handoff is accepted.

Avoid handoffs at midnight or other awkward boundaries. Scheduling guidance recommends changing shifts when both parties are in working mode.

Rotation cadence

For most teams, I'd use:

• Weekdays: regional engineers rotate weekly.
• Weekends: one regional/global weekend team covers the entire weekend, rotating weekly.
• Primary + secondary: every shift has a backup.
• After a major overnight incident: automatically give the responder recovery time rather than expecting them to immediately resume normal work.

A weekly rotation is generally easy to understand, while 12-hour shifts can make sense when you have enough people to support them.

Important design choice: don't make "follow the sun" just about time zones

Route alerts according to service expertise, not merely geography.

For example:

APAC owns payment-service alerts during APAC hours → EMEA takes over → Americas takes over.

But if the payment service is primarily owned by the Americas team, you might instead have APAC provide first response and escalate service-specific issues to the Americas specialist.

I'd also use severity-based escalation: P1s page the primary immediately and escalate quickly to the secondary; lower-severity issues shouldn't wake anyone outside their working hours. Primary/secondary escalation and clear alert routing are core on-call practices.

My preferred setup

3 regions + 1 backup layer + weekly rotations + overlapping handoffs + separate weekend rotation.

That gives you 24/7 coverage while making "I'm off call" genuinely mean off call.

If you're choosing a tool, PagerDuty and Atlassian Opsgenie both support this model, including regional rotations, handoffs, escalation policies, and schedule overrides.

If you tell me your team locations/time zones and number of engineers in each, I can lay out an exact 24/7 rotation that minimizes handoffs and individual on-call load.

• PagerDuty is an enterprise-grade incident management and on-call platform that offers robust multi-region scheduling, automated handoffs, and follow-the-sun rotation patterns.
• Opsgenie (by Atlassian) is a flexible alerting and scheduling tool with tight Jira integration, excellent for teams already using the Atlassian ecosystem to manage rotations across global time zones.
• Grafana OnCall is an open and developer-friendly option that integrates cleanly with the Grafana ecosystem, making it ideal for engineering teams focused on metrics-driven observability.
• VictorOps (Splunk On-Call) provides real-time collaboration, chatops integration, and seamless follow-the-sun handoffs tailored for fast-paced DevOps teams.
• FireHydrant is a modern reliability platform that handles on-call schedules alongside incident response workflows and retrospectives, simplifying multi-region shifts.

If you'd like, let me know:

• What monitoring or ticketing tools (like Jira, Datadog, or GitHub) you currently use
• The number of regions or time zones your follow-the-sun team spans

I can help you narrow down which tool offers the best native integrations for your stack.

• PagerDuty : Excellent for enterprise-grade management, deep integrations with monitoring tools, and sophisticated follow-the-sun routing rules across global time zones.
• Opsgenie (by Atlassian) : Strong option for teams already embedded in the Jira/Atlassian ecosystem, offering flexible scheduling, escalation policies, and clean alerting features.
• VictorOps (Splunk On-Call) : Tailored for DevOps teams, providing real-time collaboration, chatops integrations (like Slack), and straightforward shift handoffs.
• Grafana OnCall : A newer, developer-focused tool that integrates tightly with the Grafana ecosystem, making it cost-effective if you already use Grafana for observability.
• FireHydrant : Focuses heavily on incident management and reliability workflows alongside scheduling, great for streamlining the entire incident lifecycle during handoffs.

Would you like to compare these tools based on pricing, team size , or specific integration requirements?

For a true follow-the-sun team, I’d recommend regional daytime primary + local secondary, with automated escalation and a small overnight safety net.

Recommended model

The key is that the handoff should happen during overlapping working hours, not at midnight. Atlassian specifically recommends daylight-based follow-the-sun scheduling to avoid waking engineers, while retaining an overnight backup only for genuinely urgent issues.

Rules I'd use

1. One clearly accountable primary per incident. Avoid paging three regions simultaneously.
2. Primary + secondary in every region. The secondary gets paged only if the primary doesn't acknowledge/respond.
3. Handoff overlap: give regions 30–60 minutes of overlap for active incidents and context transfer.
4. Page only actionable alerts. Everything else becomes a ticket for the next business-hours team.
5. Escalate by severity, not geography. A Sev-1 can wake someone; a Sev-3 waits.
6. Use local-time schedules. Modern scheduling tools support multiple rotations and time windows, making this much cleaner than manually maintaining a giant UTC schedule.
7. Use overrides for vacations/swaps, rather than modifying the recurring rotation.
8. Measure the system: pages/person, overnight pages, MTTA, MTTR, missed acknowledgements, and percentage of alerts that were actually actionable.

Example

For a team in US / Europe / India, you might do:

India → Europe → US → India

with each region owning roughly its normal working day. The US team shouldn't inherit a pile of incidents from Europe at 5 p.m.; instead, the European engineer hands off active work during the overlap.

This is generally a better model than a traditional one-week-on/one-week-off rotation once you have enough engineers distributed across ~3+ time zones. A recent 2026 review similarly identifies follow-the-sun as the strongest fit for teams with roughly nine or more engineers across three time zones.

Tooling

For the scheduling layer, PagerDuty is a strong choice if you want mature on-call/escalation functionality; it supports follow-the-sun schedules using time-restricted layers.

Opsgenie also supports multiple rotations, time windows, overrides, and escalation policies, although I'd be cautious about choosing it for a new deployment given Atlassian's announced product direction.

Bottom line:
Follow-the-sun + regional primary/secondary + overlapping handoffs + severity-based overnight escalation is the pattern I'd choose. The schedule should make nobody wake up routinely; the escalation policy exists for the exceptional incident.