What is a follow-the-sun on-call rotation?

TL;DR: A follow-the-sun (FTS) rotation distributes pager duty across geographic regions so each team covers daylight hours and nobody takes overnight pages. The catch: every regional handoff is a potential context loss event. FTS works well for teams with mature runbooks and clear service ownership, but creates real coordination overhead for complex, exception-handling incidents. Structured handoffs, Slack-native tooling, and automated context capture separate a functioning FTS rotation from one that quietly raises your mean time to resolution (MTTR).

SRE teams often turn to follow-the-sun rotations hoping to eliminate overnight pages, only to discover that regional handoffs introduce friction of their own: coordination overhead that delays resolution and drops context between teams.

A follow-the-sun on-call rotation addresses the human cost of 24/7 coverage by distributing pager duty across geographic regions. Without structured handoffs and unified tooling, though, this model can raise MTTR through context loss. This guide explains the mechanics of follow-the-sun, details the trade-offs you must accept, and shows how to automate handoffs directly in Slack.

Decision matrix: coverage models at a glance

The follow-the-sun model

Here is what the model involves and why teams build rotations around it.

The core concept

A follow-the-sun rotation distributes pager duty across teams in different time zones, with each region covering their daylight hours and handing off to the next region at shift end. incident.io's 2026 on-call best practices guide defines it as "a global on-call model where each regional team covers their daylight hours and hands off to the next time zone, providing 24/7 coverage without overnight shifts for any individual team."

Will Larson draws a critical distinction between two types of on-call work in Don't follow the sun: "On-call should be used to handle exceptions, not to provide services." Service-providing tasks are repeatable, documented processes any engineer can execute from a runbook. Exception-handling tasks are novel, context-dependent problems requiring deep system knowledge and judgment.

FTS handles service-providing work well. For exception-handling incidents, it places enormous pressure on handoff quality, because the engineer receiving the pager at 9 AM in London was not the one who spent three hours debugging a memory leak in production.

Reasons teams adopt this model

The case for FTS is human, not commercial. Google's SRE Book is blunt that night shifts have detrimental effects on people's health, and identifies multi-site rotations as the way to avoid them altogether.

FTS distributes the load across regions so alert response happens during daylight hours, making senior SRE roles more sustainable over multi-year careers. That matters commercially as well as humanely: as Uptime Labs puts it, burnout and boredom drive attrition, and losing a senior engineer can mean months of rehiring and retraining. The incident.io team covers how on-call itself is changing across the industry in how on-call is changing.

Follow-the-sun vs. traditional on-call

The differences become clear when you compare how each model handles coverage, fatigue, and context across regions.

Single-region rotation limitations

In a single-region rotation, one team carries the pager around the clock. A P1 (priority-one incident) firing at 2 AM wakes an engineer who assembles context before troubleshooting with degraded cognitive performance. Coordination overhead alone typically runs 10 to 15 minutes before anyone touches the actual problem. Google's SRE Book identifies the mechanism directly: stress hormones released during a night-time page impair cognitive functions and cause suboptimal decision making. The engineer you wake at 2 AM is measurably worse at the job than the same engineer at 2 PM.

Multi-region coverage trade-offs

FTS is not the same as multi-region independent coverage, where each region owns its own infrastructure and handles alerts separately. FTS typically applies when you have a shared, global service and want one coordinated engineering team to cover it in rotating shifts. Independent multi-region coverage requires hiring and maintaining fully staffed engineering teams in each region, whereas FTS lets you share a global team across shifts, though each region still needs enough headcount to sustain its own rotation.

Timezone fairness vs. context continuity

FTS creates a central tension: you gain timezone fairness, where engineers avoid overnight pages, but you lose context continuity, where the engineer who started the investigation may not be the one who finishes it. That trade-off is manageable for a flapping alert on a well-understood service. It is punishing for a P0 mid-investigation, where the incoming region is effectively solving a crime scene with no photos. Every FTS implementation must answer one question before launch: how do you transfer deep incident context across a timezone boundary without losing the thread?

Core mechanics of follow-the-sun rotations

The following sections break down how a functioning FTS rotation is structured in practice.

Regional handoff windows

Teams divide the 24-hour day into regional shifts, with an overlap window between regions where both teams are active and the outgoing team briefs the incoming team. A common three-region structure distributes coverage across US, EMEA, and APAC, with each region covering approximately 8-hour shifts and handing off to the next zone. Two-region models with 12-hour shifts can work for teams with enough headcount concentrated in two locations, though they leave transition gaps.

During the handoff window, the outgoing team must:

1. Post an active incident summary covering open, mitigated-but-not-resolved, and under-investigation incidents
2. List ongoing concerns such as deploy freezes and known-flapping alerts
3. Document recent changes the incoming team needs to know
4. Share runbook gaps or operational learnings from the shift

Set each region's timezone when you create its schedule. It is fixed at creation and cannot be changed afterward, so a three-region rotation means three separate schedules from the start.

Primary and secondary coverage roles

Most FTS implementations define a primary and secondary responder for each shift. The primary owns active alerts and coordinates incidents for their shift. The secondary acts as the first escalation path if the primary doesn't acknowledge within the configured escalation delay. Getting that delay right is critical for FTS, because the incoming region may not be fully active at the exact moment a handoff-window alert fires.

Escalation paths in FTS also need a global fallback: if neither the primary nor secondary in the active region responds, the escalation should cross regional boundaries rather than page nobody. incident.io's Pro plan, at $45/user/month with on-call ($25 base plus $20 on-call add-on), supports unlimited schedules and multi-level escalation paths, where each level can point at a different regional schedule. On-call schedules explicitly support follow-the-sun for 24-hour global coverage.

Handoff format and discipline

Uptime Labs is direct on where this model lives or dies: a follow-the-sun model succeeds or fails at the handover boundary, and most failures come from context loss between teams rather than from the idea of global coverage itself.

That makes the format of the handoff, not its existence, the thing worth designing. Post the four categories above as a written summary in the incident channel rather than delivering them verbally, because the written version survives after the call ends and the outgoing engineer logs off. Where the two regions overlap, run the handoff synchronously and use that summary as the agenda rather than a replacement for it. The incident.fm podcast on building an on-call team covers the cultural discipline this requires.

Conditions where regional handoffs work well

Several conditions make FTS a strong fit for a given team and service environment.

Distributed teams with mature runbooks

FTS works best when your runbooks are mature enough that an engineer in any region can execute mitigation steps without relying on tribal knowledge. The automated runbook guide from incident.io covers how to build runbooks that reduce cognitive load during handoffs rather than adding to it.

Services with clear ownership boundaries

FTS becomes significantly simpler when each service has a documented owner visible to every region. A service catalog that maps alerts to owning teams, escalation paths, and runbook locations removes the "who do I page?" question during a regional handoff. Investigations, incident.io's AI SRE product, reads the incident channel, the alert payload including errors and stack traces, the timeline, and connected sources such as past incidents and telemetry, so the arriving region's engineer isn't starting from zero.

Teams prioritizing work-life balance

Eliminating overnight paging is one of the most concrete ways to reduce burnout-driven attrition. Offering a rotation where no engineer is paged outside business hours makes senior on-call positions far more sustainable. The incident.io on-call survey found that over 40% of respondents are not compensated for on-call at all, and that nearly 70% of organizations leave each team to own its own rotation. Both matter when you are asking several regions to run one coordinated rotation.

Trade-offs teams accept with follow-the-sun

Adopting FTS means accepting a set of known costs alongside its benefits.

Context loss during handoffs

The argument against FTS as a long-term model comes from experienced SRE practitioners. Larson argues that "follow the sun will appear to solve all of these problems, but won't solve any of them effectively in the long-term," pointing at long incident remediation times and stressful on-call shifts. His recommendation is to move toward fully automated solutions and push human remediation upstream into game days and architecture, where it isn't user-impacting. For teams with complex, novel incident types requiring deep system context, the engineering investment FTS demands may be better directed there.

Coordination overhead between regions

Even with good documentation, every FTS handoff carries a coordination tax. If your outgoing engineer must update PagerDuty, post a Slack summary, update a Jira ticket, and edit a Confluence page before handing off cleanly, that handoff becomes a source of toil. incident.io's blog on scheduling rotation models makes the point clearly: SRE teams spend more time debating on-call scheduling than almost any other operational decision.

The bigger burnout driver goes overlooked, the time spent toggling between PagerDuty, Datadog, Slack, and a Google Doc just to assemble the team. For FTS, that tax shows up at every handoff window. Teams migrating from PagerDuty cite that coordination overhead as a primary motivation.

Incident complexity and handoff timing

A common FTS challenge: a P0 (priority-zero incident) fires shortly before a regional handoff window. The outgoing engineer is mid-investigation, the incoming team isn't fully briefed, and any handoff at that moment risks dropping critical context. The correct protocol requires the outgoing engineer to remain as incident lead until the incoming engineer explicitly accepts the handoff in the incident channel and confirms they've read the status summary.

incident.io's guidance on incident roles is explicit that the outgoing lead should make the current status clear before the next person picks up, and the role is reassigned in Slack with /inc role lead, so the transfer is recorded in the channel rather than agreed verbally on a call.

Common implementation challenges

Even well-designed FTS rotations run into recurring operational problems during rollout and at scale.

Uneven regional expertise

Regions can carry different levels of familiarity with different services, especially in companies that grew organically from one founding location. This can create asymmetric risk, where one region knows certain services deeply while having less context on others. Close that gap through cross-regional training or by investing in automation that reduces the expertise requirement for first-response steps.

Cost-benefit analysis: FTS global teams vs. automated infrastructure

This is not a binary choice. Many teams run a hybrid: automate known failure modes to reduce alert volume, and use FTS for the novel incidents requiring human judgment. The incident.io AI platform page describes how Investigations lowers the expertise requirement for first response by surfacing related past incidents and suggesting next steps, directly in the incident channel.

Handoff process gaps

Informal handoffs are where FTS rotations fail silently. When the outgoing engineer posts a casual "looks stable, handing off" without a structured summary, the incoming region starts their shift from near-zero. Uptime Labs puts it bluntly: handoffs fail when they rely on memory, and a verbal "it was a quiet week" at shift changeover is not a handoff, it is an invitation for the incoming engineer to rediscover everything the outgoing engineer already knew.

Segment your MTTR data by whether an incident crossed a handoff boundary. That single comparison tells you what your handoffs are actually costing, and it is the metric most FTS teams never track.

FTS readiness checklist

• Do you have 3-5 engineers per location across at least three regions for full coverage, or enough depth in two regions to accept the transition gaps?
• Are your escalation paths and service ownership boundaries documented in a centralized service catalog?
• Do you have tooling to coordinate incidents and capture timelines automatically?
• Are your runbooks mature enough for an engineer in a different region to mitigate an alert without tribal knowledge?
• Have you established a formal, timezone-aware handoff window with clear ownership transition protocols?

Tooling that doesn't support handoffs

Legacy tools treat on-call as a static calendar: they tell you who carries the pager but don't coordinate the handoff. If your tooling can't automatically post an active incident summary to the incoming region's Slack channel at shift start, your engineers fill that gap manually, and some handoffs will be thorough while others are not.

incident.io's Slack-native architecture changes the handoff calculus. Because the entire incident lifecycle runs inside Slack, the outgoing region's incident channel is already the source of truth: timeline captured, decisions logged, status posted. The incoming engineer joins the channel, reads the auto-captured timeline, and has full context without a synchronous briefing call. Scribe, incident.io's real-time transcription feature, captures what is said on the outgoing team's incident call and surfaces key moments and summaries. Those Scribe transcripts feed into the investigation as evidence, just like the messages in the channel do.

Investigations automates up to 80% of incident response by connecting telemetry, code changes, and past incident history to surface likely root causes directly in Slack. For the incoming region, this means arriving at a handoff with a structured investigation already in progress rather than starting triage from scratch. It never acts on its own: the only change Investigations can make to your systems is a pull request you review and merge yourself. Watch this in action in the incident.io On-call overview.

For teams migrating from PagerDuty or Opsgenie, incident.io supports importing existing schedules and escalation policies directly, removing the configuration tax of rebuilding your rotation from scratch. You can also sync schedules with Slack user groups. The group's membership updates the moment a handoff occurs, so mentioning the group in an incident channel always reaches whoever is currently on-call, not whoever was on-call when the incident opened.

The Fin case study is worth reading for any team evaluating this stack. Fin migrated from PagerDuty and Atlassian Status Page to incident.io and documented faster incident resolution, reducing MTTR and minimizing downtime as outcomes of centralizing their incident coordination in one platform.

"Our engineers immediately preferred incident.io over PagerDuty, and adoption across the broader company quickly followed." - Mark G., Technical Program Manager, Fin

The Pro plan, at $45/user/month with on-call ($25 base plus $20 on-call add-on), includes Scribe, Investigations, unlimited on-call schedules, and escalation paths. For teams running a two or three-region FTS rotation, the Pro plan supports core handoff coordination without per-incident fees.

The bottom line

FTS is not a fix for MTTR on its own. It fixes the human cost of overnight paging, and in exchange it moves your risk to the handoff boundary. Teams that succeed with it share three things: runbooks mature enough that any region can act on them, service ownership documented where every region can see it, and tooling that carries context across the boundary without anyone remembering to do it manually. If those three are missing, fix them before you redraw the rotation. A handoff process built on memory will cost you more than the overnight pages ever did.

Book a demo of incident.io and see your first incident coordinated in Slack.

Key terms glossary

Follow-the-sun (FTS): Each regional team covers their daylight hours and hands off to the next timezone, providing 24/7 coverage without overnight shifts for any individual team.

Handoff window: The overlap period between regional shifts where both the outgoing and incoming teams are active and the outgoing team transfers incident context.

Service-providing vs. exception-handling: Service-providing tasks follow repeatable, documented scripts. Exception-handling tasks demand novel, context-dependent judgment. FTS handles service-providing work well but requires automated context capture for exception-handling incidents.

MTTR (Mean Time To Resolution): The average time from incident detection to full resolution, including root cause identification and any follow-up fixes. In FTS implementations, handoff quality and automated context capture are critical variables that affect MTTR outcomes.

Investigations: incident.io's AI SRE product that analyzes telemetry, code changes, and past incidents to surface root causes, automating up to 80% of incident response and lowering the expertise requirement for the incoming region's first-response steps. Available on the Pro and Enterprise plans.

Scribe: incident.io's real-time call transcription feature that captures decisions and key moments from incident calls, making that context available to the incoming region without a synchronous briefing call. Available on the Pro and Enterprise plans.