The appeal of follow-the-sun is simple: keep support, operations, or incident response covered around the clock without asking anyone to work nights. The catch is that it only works if the geography lines up and the handoffs are deliberate. Get the spacing wrong and you have a gap at 3am that nobody owns. Get the handoff wrong and work falls through the crack between two shifts every single day. Here is how to lay it out properly, with the coverage math, a worked example, and the parts that quietly break.
What follow-the-sun actually means
Follow-the-sun is a coverage model, not a meeting pattern. Instead of one team stretching its hours or being woken up overnight, you place teams in two or three regions spaced across the globe and pass in-flight work from one to the next as each region's day ends. A ticket opened at noon in Manila that is still unresolved at 6pm there does not wait until morning. It moves to the European team who are mid-afternoon, and if it is still open when Europe logs off, it moves again to the Americas. The sun never sets on the work, but no individual works in the dark.
That is the difference from an on-call rotation, where the work stays put and a person gets paged out of bed. Follow-the-sun trades the staffing cost of three daytime teams for the human cost of nobody losing sleep. It is the right model when you have, or can build, genuine presence in multiple regions, and the wrong one when you are trying to fake 24 hour coverage out of a single small team.
The coverage math: three hubs on one clock
The whole model rests on one number: roughly eight hours of offset between adjacent hubs. A standard nine-hour working day, three times over with a little overlap, just about wraps the 24-hour clock. To check whether a given set of locations actually covers the day, do what you would do for a meeting: convert every team's working hours to UTC and lay them on a single line. Local clocks lie to you here, because each region's 9am is a different instant.
Take a classic triad in June 2026, with each team working 09:00 to 18:00 local:
- Manila (UTC+8, no daylight saving): 01:00 to 10:00 UTC.
- London (UTC+1 in summer): 08:00 to 17:00 UTC.
- San Francisco (UTC-7 in summer): 16:00 to 01:00 UTC the next day.
Lay those three windows end to end and the clock is covered. San Francisco runs from 16:00 UTC through to 01:00, Manila picks up at 01:00 and runs to 10:00, London covers 08:00 to 17:00, and San Francisco is back at 16:00. There is no uncovered hour. You can build this map by hand, or drop the three cities into the team time zone planner and read the combined strip directly, and confirm individual offsets with the time zone converter before you commit.
The handoff is the whole game
Covering the clock is necessary but not sufficient. The model lives or dies on the seams between shifts, and the coverage map above hides a real problem at one of them. Look at where the windows meet:
- Manila ends 10:00 UTC, London is already online from 08:00. Overlap: two hours.
- London ends 17:00 UTC, San Francisco came online at 16:00. Overlap: one hour.
- San Francisco ends 01:00 UTC, Manila starts at 01:00. Overlap: zero.
The first two handoffs have a live overlap window where both teams are online and can talk through anything tricky. The third, San Francisco to Manila, only touches at the boundary. There is no shared minute. If an incident is mid-investigation when San Francisco logs off, there is nobody awake to brief, and Manila walks into it cold. This is the failure that people blame on follow-the-sun when really they just never built an overlap into the weakest seam.
You have two fixes. Shift one team's hours to manufacture an overlap, for example moving Manila to an 08:00 start so it comes online at 00:00 UTC and shares an hour with San Francisco. Or, where a live overlap is genuinely impossible, make the written handoff mandatory rather than a nicety, so the work survives even with nobody to hand it to in person. In practice you want both: an overlap where you can get one, and a written record everywhere regardless.
A worked handoff that does not drop the ball
Suppose at 00:45 UTC, fifteen minutes before San Francisco logs off, an order-processing job is failing intermittently and the on-shift engineer has narrowed it to a flaky downstream dependency but not fixed it. A clean handoff to Manila looks like this:
- State, not story. Write down what is broken, what has been ruled out, the current hypothesis, and the exact next step you would have taken. Manila should be able to continue, not re-investigate from scratch.
- Links, not memory. Attach the failing job, the relevant logs, the dashboard, and any change you already made. Anything that lives only in the outgoing engineer's head is lost at 01:00 UTC.
- An explicit owner. Name the Manila person or queue that now owns it, so it is not left addressed to a whole region, which means addressed to nobody.
- Severity and clock. Note how urgent it is and when it was last touched, so the receiving team can triage it against whatever else landed overnight.
Because there is no live overlap on this seam, the written record is the entire handoff. When Manila comes online at 01:00 UTC they read the note, not a person. The same discipline that makes a good asynchronous standup work makes a good handoff work, and the async-first standup playbook covers how to write state-not-story updates that the next reader can act on without a meeting.
Where follow-the-sun quietly breaks
Daylight saving. The eight-hour spacing you carefully arranged in June is not the same in January. When London falls back to UTC+0 in late October 2026 but Manila stays on UTC+8, the offset between them widens by an hour, and a handoff window that was comfortable can shrink or a small gap can appear. Anchor each hub to its IANA zone, such as Asia/Manila or Europe/London, never a frozen offset, and recheck the coverage map at every transition. The hardest weeks are the ones where two regions shift on different dates, which the daylight saving survival guide lists in full for 2026.
Public holidays. Coverage that assumes three staffed regions has a hole the moment one region takes a national holiday the others do not. If your Manila hub is off for a local holiday, the 01:00 to 10:00 UTC band is suddenly uncovered, and the teams on either side may not even know. Maintain a shared calendar of every hub's holidays and plan backfill in advance; the guide to public holidays for distributed teams explains how to spot these clashes before they bite.
Single points of failure. A hub of one person is not a hub, it is a person who cannot ever be ill, on leave, or in a long meeting. Each region needs at least two people who can take the handoff, or the model collapses to on-call the first time someone is away.
Half-hour zones. If a hub sits in India at UTC+5:30 or central Australia at UTC+9:30, round it to the nearest hour and your handoff window is off by thirty minutes, which is enough to erase a thin overlap. Use the exact offset when you build the map.
When not to use follow-the-sun
Follow-the-sun is not free, and for many teams it is the wrong tool. If your overnight volume is low and sporadic, three staffed regions is expensive overkill, and a single region with a paid on-call rotation handles the occasional 3am page more cheaply. If the work needs deep, uninterrupted context that cannot survive a handoff, such as a complex investigation where re-briefing costs more than it saves, passing it across regions every eight hours makes it worse, not better. And if you only have presence in two nearby zones, say London and Berlin, you do not have follow-the-sun, you have two teams in almost the same daytime: fine for resilience, useless for overnight coverage. Be honest about which problem you are solving before you reorganise people around the globe to solve it. You can sanity-check the real daytime spread of your existing offices with the world clock before assuming the geography supports the model at all.
A setup checklist
- Convert every hub's working hours to UTC and lay them on one line.
- Confirm the combined windows cover all 24 hours with no gap.
- Check the overlap at every seam, and build a thirty to sixty minute handoff window.
- For any seam with no live overlap, make the written handoff mandatory.
- Define a handoff format: state, links, explicit owner, severity, last-touched time.
- Staff each hub with at least two capable people so one absence does not break it.
- Anchor hours to IANA zones, not fixed offsets, and recheck at every DST transition.
- Track every hub's public holidays and plan backfill before the clash arrives.
Frequently asked questions
What is the follow-the-sun model?
It is a way of providing continuous coverage by handing work from a team in one time zone to a team several zones west as the first team's day ends. Each team works only its normal daytime hours, but because the hubs are spaced roughly eight hours apart, the combined coverage spans a full 24 hours with nobody on a night shift.
How many locations do you need for 24-hour follow-the-sun coverage?
Three hubs spaced about eight hours apart in offset is the standard pattern, because a normal nine-hour working day in each covers the clock with a little overlap for handoff. Two hubs can cover roughly sixteen hours, which is enough for extended business hours but leaves a gap overnight in one of the regions.
What is the difference between follow-the-sun and an on-call rotation?
Follow-the-sun keeps people in their daytime hours and moves the work to whoever is already awake. An on-call rotation keeps the work in one place and wakes someone up to handle it. Follow-the-sun is humane but needs three staffed regions; on-call is cheaper to staff but pays for it in interrupted sleep.
How do you stop work being dropped at a follow-the-sun handoff?
Build a deliberate overlap window of thirty to sixty minutes where both teams are online, and require a written handoff for every in-flight item so nothing depends on a live conversation. If two hubs only touch at the boundary with no overlap, the written handoff becomes mandatory rather than optional.
Does daylight saving time break a follow-the-sun schedule?
It can. When one hub shifts its clocks and another does not, the offset between them changes by an hour, which can open a coverage gap or shrink a handoff window for several weeks. Anchor each hub's hours to its IANA time zone rather than a fixed UTC offset, and recheck the coverage map at every transition.