Key takeaways
- Follow-the-sun on-call fixes the fatigue problem of one timezone carrying every 3 a.m. page, and creates a different one: ownership that spreads across every handoff instead of sitting with one accountable person.
- The usual failure isn't a missed page. It's a page someone acknowledges without the context to act on it, because the previous shift's understanding of the incident didn't transfer.
- A real handoff needs a written artifact, not a verbal aside in a chat channel, plus a named owner for each open incident and an explicit answer to "who owns this until the next handoff," not an assumption that whoever's awake will figure it out. That includes a clear rule for pages that fire right at the shift change.
The trade-off of follow-the-sun on-call
A single-timezone on-call rotation has an obvious problem: the same few people absorb every overnight page, indefinitely. Spreading the rotation across time zones, so someone is always in their normal working hours, fixes that. Google's SRE book makes the same case: night shifts are bad for people's health, and a multi-site follow-the-sun rotation lets a team avoid them entirely.
It also introduces a problem that gets discussed far less: an incident that spans a shift boundary now has no single person who owned it from start to finish. Ownership becomes a relay, and relays drop batons.
This isn't an argument against follow-the-sun rotations. The fatigue problem they solve is real (we wrote about why it outlasts every tooling change in why alert fatigue survives every tooling migration). The point is that the ownership problem needs its own explicit fix. Most teams get the scheduling mechanics right, meaning which region covers which hours, without solving it at all.
Where follow-the-sun ownership breaks down
Context loss at handoff: the engineer going off shift knows things that don't transfer by themselves: what's been tried, what's been ruled out, what looked promising but isn't confirmed. If that lives only in their head, or scattered across a chat thread the next person has to reconstruct, understanding is lost at every handoff, and a multi-day incident has many handoffs.
Escalation policies written for one timezone: a policy that escalates to "the engineering manager" after 15 minutes assumes that person is reachable at any hour. Follow-the-sun is supposed to guarantee someone is, but the policy often wasn't rewritten to match who is actually awake and accountable at each point in the cycle. It still names one person by title, not "whoever owns this shift block."
Unclear ownership during the handoff window: the ten or twenty minutes around a shift change are the riskiest part of the day. Is the outgoing engineer still responsible for a page that fires at the boundary, or does the incoming one own it immediately? Without an explicit answer, both sides can reasonably assume the other has it, which is how a page ends up acknowledged late by neither.
Nobody owns "did this actually get fixed": with a single on-call person, they own an incident until it's resolved, by default. Across shifts, "resolved" can quietly turn into "no longer paging," which isn't the same thing. Nobody notices until the issue comes back on a shift that has no memory of the first time.
What real ownership requires
A named owner per incident, independent of whose shift it is: not "whoever's on call right now" but a specific person, usually whoever first triaged it or the incident commander assigned at declaration. They're accountable for the outcome across however many handoffs it takes, even if they're asleep for some of them and pick it back up on their next shift.
A written handoff artifact, every time, not just for the complicated cases: a short, structured note (what happened, what's been tried, what's still open, what to watch for) written by the outgoing person and read by the incoming one before they take the pager. The easy cases don't need it. The problem is you don't know which case you're in until the handoff has already gone badly. Google's SRE workbook describes the same habit in its on-call chapter: read the previous shift's handoff when you start, send one when you finish.
Escalation policies that name a role and a rotation, not a person, and get regenerated as the rotation changes: if "engineering manager" always resolves to the same person regardless of timezone, that's a single-timezone policy with a follow-the-sun label on it. Make each escalation step point at a rotation, and regenerate the policy when the rotation changes. If those policies only live in a vendor UI with no review before a change ships, that's a related and worse problem; see escalation policies as code for the fix.
An explicit boundary rule for pages that fire at the shift change: pick one and write it down. For example: the outgoing person owns anything that fired before the boundary, the incoming person owns everything after, communicated clearly enough that neither side has to guess. Any consistent rule beats an implicit one.
A handoff note template
A handoff note doesn't need to be long. These five lines cover most shifts:
- Open incidents: each one with its current owner and status.
- What's been tried: including what was ruled out, so the next person doesn't repeat it.
- What's still unknown: the open questions, stated plainly.
- What to watch: alerts or dashboards that are likely to fire, and what they'd mean.
- Changes in flight: deploys, migrations, or config changes that could explain new pages.
Keep it in one place the incoming person will definitely read, such as the incident channel or the incident record, not a DM.
FAQ
What is follow-the-sun on-call? A rotation where on-call duty passes between teams in different time zones over the day, so each person is on call during their own working hours instead of overnight.
Does follow-the-sun make sense for a small team? Usually not below a certain size. You need enough people in each timezone to actually build a rotation there, not just one person covering "their" hours alone, which just relocates the fatigue problem rather than distributing it. Google's SRE book suggests a minimum of six engineers per site for a two-site team.
How long should a handoff note take to write? A few minutes for a quiet shift, longer for an active incident. If it regularly takes much longer, the incident wasn't documented well enough during the shift. The handoff note is the symptom, not the real gap.
Who should write the handoff note, outgoing or incoming? Outgoing, while the context is still fresh. The incoming person's job is to read it and ask questions before taking the pager, not to reconstruct it from scratch.
What tools support follow-the-sun scheduling? Most on-call schedulers support per-schedule timezones and handoffs at set hours. For a comparison of self-hosted options and how each handles timezones, see 10 best self-hosted on-call scheduling tools.
One disclosure: we build FluidifyAI Regen, and this gap is why it has AI-generated handoff digests. They draft the "what happened, what's open, what to watch" note from the incident timeline, so a note exists even on the shifts where nobody had time to write one.