"Follow the sun" is the pattern where a single workstream — usually customer support, on-call rotation, security operations, or live moderation — moves around the globe so that someone is always awake to handle it. Done well, it eliminates 3am pages and gives every region predictable working hours. Done badly, it just shifts the same human into the wrong shift permanently and produces a quiet attrition wave six months later.
This post is a practical playbook for designing a follow-the-sun rotation that stays sustainable. It covers the time-zone arithmetic, the shift boundaries, the handoff ritual itself, and the failure modes we see most often.
The minimum viable geography
To cover 24 hours with no shifts longer than nine hours, you need at least three regions. Two regions cannot do it without one side regularly working past midnight. Four regions makes the math easier and gives breathing room around DST shoulders. Most teams pick from this set:
- Americas: typically anchored in New York, Chicago, Denver, or San Francisco. The four US zones cover six hours, which is useful for staffing flexibility within the region.
- Europe / Africa: typically London, Dublin, Berlin, or Lisbon. EMEA covers about three hours of internal spread; African hubs (Lagos, Nairobi, Cape Town) extend it.
- Asia / Pacific: typically Bengaluru, Singapore, Tokyo, or Sydney. APAC covers about six hours of internal spread, which is the largest of the three regions.
The three-region default — Americas, EMEA, APAC — produces three eight-hour shifts. The four-region variant adds India as its own block, which works well when India is genuinely the busiest support region and pulling it out of APAC reduces handoff complexity.
Design the shifts in UTC, then translate
The single most important habit is to express the shift schedule in UTC, not in any region's local time. UTC does not observe DST, so a shift defined in UTC has stable boundaries year-round. A shift defined as "9am London to 5pm London" silently shifts by an hour twice a year, and the handoff window that worked in winter no longer aligns in summer.
Here is a concrete three-shift plan for an Americas / EMEA / APAC team, all anchored in UTC:
| Shift | UTC window | Anchor city local hours (winter) | Anchor city local hours (summer) |
|---|---|---|---|
| APAC | 00:00 – 08:00 UTC | Singapore: 08:00 – 16:00 | Same (no DST) |
| EMEA | 08:00 – 16:00 UTC | London: 08:00 – 16:00 | London: 09:00 – 17:00 |
| Americas | 16:00 – 00:00 UTC | New York: 11:00 – 19:00 | New York: 12:00 – 20:00 |
Notice that the APAC anchor is constant year-round (Singapore does not observe DST), the EMEA anchor shifts within an acceptable working band, and the Americas anchor lands in the late-morning-to-evening slot. The Americas shift is the one most teams adjust first, often by anchoring to Chicago or Denver instead of New York to pull the working hours earlier.
Handoff windows, not handoff moments
The naïve design is for one shift to "end" exactly when the next one "begins." That guarantees information loss at every transition. The better pattern is to budget a 30-to-60-minute overlap, during which both shifts are nominally on duty and the outgoing engineer narrates the state of the world to the incoming one.
For the schedule above, a 30-minute overlap means each shift is paid for 8.5 hours and overlaps the previous shift's last 30 minutes. The handoff ritual fits in that overlap. Three rules that keep the ritual fast:
- Write before you talk. The outgoing engineer posts a structured handoff note 5–10 minutes before the live overlap. The incoming engineer reads it before joining the call.
- Talk only about ambiguity. The live conversation covers things that did not fit in the note: judgement calls, escalations that may resurface, things you suspect but cannot prove.
- End with a single yes/no question. "Do you have what you need to take the queue?" — the outgoing engineer does not leave until the incoming engineer says yes.
The handoff note has a fixed structure that everyone reuses: currently active incidents, watchlist items, changes deployed in this shift, known fragility, open customer threads expecting follow-up. Anything not in those buckets is forgotten on purpose; if it mattered, it would already be in the runbook or the ticket.
The fairness problem
"Each region works their local daytime" is the idealized version of follow-the-sun. In practice, the three regions are not perfectly distributed around the globe, and one or more shifts will land at uncomfortable local hours.
Consider the four-region variant with India added. To cover 24 hours with shifts of 6 hours each, the schedule becomes APAC 00:00–06:00 UTC, India 04:00–12:00 UTC (with a 2-hour overlap into APAC), EMEA 10:00–18:00 UTC, Americas 18:00–02:00 UTC. The India shift's wall clock is 09:30–17:30 IST, which is excellent. APAC's shift is 08:00–14:00 in Singapore (also excellent) but 09:00–15:00 in Sydney — early afternoon in Australia is fine, but late afternoon coverage moves to India. The Americas shift ends at 02:00 UTC, which is 21:00 ET / 18:00 PT — the late edge of the US working day, but acceptable.
The shift that tends to be ugliest is whichever one bridges Asia and Europe. If your three regions are Americas / EMEA / India, then India absorbs the Asia-Pacific load on its early shift; if your three regions are Americas / EMEA / Singapore, then Singapore absorbs the early-morning-Asia load. Either way, one team ends up doing the inconvenient piece. The honest answer is to pay for it explicitly — shift premium, additional time off, dedicated quiet days — rather than pretending it is not happening.
What breaks at DST shoulders
Every spring and autumn, two of your three or four regions shift their local clocks at slightly different dates while the others do not. The UTC anchor protects you from real schedule drift, but the local-time labels in chat, status pages, and customer communications all shift by an hour. If your support tool displays "next response by 3pm London time," that label means a different UTC moment in winter and summer. The defensive habit is to display all customer-facing time commitments in either the customer's zone or in UTC, and to display all internal coordination times in UTC only. We have a deeper post on the underlying mechanics in DST and meeting planning.
On-call rotations are different
Follow-the-sun support and follow-the-sun on-call look superficially similar but solve different problems. Support handles known classes of work that are bounded in time — a ticket comes in, gets resolved or escalated, the agent moves on. On-call handles unpredictable failure that may arrive at any moment and may take hours to resolve. The shift schedule for support can be tight; the on-call schedule needs slack.
For on-call specifically: the engineer on duty should be in their working day at the moment a page is most likely to fire. If your service has a usage peak at 18:00 UTC (a common pattern for B2B SaaS serving North America), then on-call coverage at that moment should belong to whoever is in their working hours, which is EMEA — not the Americas team that just signed on. Use traffic data to position on-call against the times when failure is likeliest, not against the times when humans are most available.
What to verify before you launch the rotation
- Run the proposed shift schedule through Schedule for each adjacent pair of regions and confirm the handoff window lands in everyone's working day.
- Check the schedule at four points across the year: mid-January, mid-April, mid-July, mid-October. Three of those four cross a DST shoulder. If any handoff window goes outside the working day during a shoulder, redesign the schedule, do not patch around the shoulder.
- Build the handoff note template before the first shift starts. Templates that are improvised in the first week tend to set bad defaults.
- Decide who owns escalations that span shifts — the originating shift, the receiving shift, or a separate on-call. Document the rule and put it where the handoff ritual happens.
Further reading
- Scheduling meetings across time zones without the headache — the basics that follow-the-sun design depends on.
- Coordinating four-region all-hands meetings — the synchronous version of the same multi-region problem.
- How to plan a rotating meeting fairly — fairness patterns for slots that always favor one region.
- DST and meeting planning — what shifts twice a year and why your handoff windows can drift.