Follow the sun on-call rotation: what it is, when it makes sense, why the classic setup breaks
Follow the sun on-call hands alerts to whichever region is awake. When it applies, the layered-schedule setup and its failure modes, a 3-region example, and a nudge-then-page model.
Sandeep Sidhu · Founder, AlertKick
A follow the sun on-call rotation hands responsibility for alerts to whichever region is in its working day, so that an engineer who is awake and at their desk takes the alert instead of a colleague being woken on the other side of the world. It only makes sense when the team has real timezone spread, at least two regions whose working hours do not overlap much. The classic implementation, one schedule per region layered together with time-based routing rules, works but breaks quietly at daylight saving changes, at weekends and at the handover boundaries, because the routing logic lives outside any single schedule and nobody owns it. The alternative is to keep one plain rotation and make the alerting algorithm timezone-aware.
This post covers what follow the sun is, how to decide whether a team is actually spread enough to benefit, the classic layered implementation with a worked 3-region example, the ways it fails, and how AlertKick models the same thing as a schedule type. For the basics of rosters and rotations that this builds on, see the on-call roster guide and how to create an on-call schedule.
What is follow the sun on-call?
Follow the sun is an on-call arrangement in which the region currently in working hours handles alerts. Responsibility moves westward as each region’s day ends and the next one’s begins. The name comes from the idea that the pager follows daylight.
In practice it is a routing decision layered on top of an ordinary rotation. The rotation still says who is on call this week. Follow the sun adds a rule: if the assigned person is outside their working hours and someone in another region is inside theirs, ask the awake person first. The rota engineer remains the backstop.
Follow the sun is not a replacement for the rotation. If nobody in the awake region acknowledges, the alert still reaches the person accountable for it. That person is whoever the rota names. Without that backstop, follow the sun becomes a way for alerts to go unowned during a busy afternoon in the awake region.
When does follow the sun on-call make sense?
When at least two regions have working hours that cover a slice of the day the other does not, and when engineers in each region can act on the alerts the other region’s services produce.
The first condition is about geography. Some examples:
| Team spread | Working hours (UTC, summer) | Follow the sun worth it? |
|---|---|---|
| London and Berlin | 08:00-17:00 and 07:00-16:00 | No, one hour of difference |
| London and New York | 08:00-17:00 and 13:00-22:00 | Marginal, covers the evening only |
| London and Sydney | 08:00-17:00 and 23:00-08:00 | Yes, near-complete night cover |
| London, New York and Sydney | See below | Yes, near-24-hour cover |
A team with a five-hour spread gains a few evening hours; a team with an eight-hour spread gains the night. Below about six hours of offset the extra machinery is not worth its maintenance cost, and a normal rotation with well-tuned escalation levels is the better answer.
The second condition is about capability. If the Sydney engineers do not have access to, or context on, the services the London engineers own, routing London’s alerts to Sydney just adds a five-minute delay before the London engineer is woken anyway. Follow the sun assumes a shared ownership model, shared runbooks and shared access. Teams that are split by product rather than by function often find that only a subset of alerts can genuinely cross regions, and it is reasonable to apply follow the sun to that subset only.
How is follow the sun on-call usually implemented?
The classic approach uses one on-call schedule per region, stacked as layers so that the region whose working hours contain the current time is the active layer, plus time-based routing rules that send alerts to the right schedule. Most established on-call tools model it this way, and it works.
A 3-region example, with each region working an eight-hour local day:
| Region | Local hours | Timezone | UTC (winter) | UTC (summer) |
|---|---|---|---|---|
| APAC | 09:00-17:00 | Australia/Sydney | 22:00-06:00 | 23:00-07:00 |
| EMEA | 09:00-17:00 | Europe/London | 09:00-17:00 | 08:00-16:00 |
| AMER | 09:00-17:00 | America/New_York | 14:00-22:00 | 13:00-21:00 |
Two things are visible in that table straight away. There are gaps: in winter, 06:00-09:00 UTC has nobody on shift, and 17:00-14:00 is covered only because AMER overlaps EMEA. And the gaps move: Sydney’s daylight saving runs opposite to London’s and New York’s, so the winter and summer columns are different shapes, and there are several weeks a year when only some of the regions have changed.
The layered-schedule version of this needs three rosters, one per region, each with its own rotation, and a set of routing rules of the form “between 22:00 and 06:00 UTC route to apac-oncall”. The escalation policy then points at all three, relying on only one of them having an active member at any given time.
Why does the classic follow the sun setup break?
The logic that decides which region is awake lives in routing rules outside any schedule. Rules written in a fixed timezone are wrong for part of the year.
The specific failure modes:
- Daylight saving. Rules written in UTC drift by an hour when a region changes its clocks. The three regions above change on different dates. For several weeks a year the rule says APAC is on shift when APAC has gone home. Rules written in local time avoid this for that region but then cannot be compared against the other regions without conversion.
- Gaps that nobody chose. The 06:00-09:00 UTC hole above is easy to see in a table and easy to miss in a routing UI. When an alert fires in a gap, it routes to a schedule with nobody on it or falls through to a default that someone set up a year ago and nobody remembers.
- Weekends. Working-day shifts do not cover Saturday and Sunday. A separate weekend rota is needed, and the routing rules have to know which day it is in which timezone. Sunday evening in Sydney is Sunday morning in London.
- Ownership. Three rosters have three owners. The routing rules have none. When the team in one region changes its hours, the rules are not updated.
- No backstop. If the awake region is busy and nobody acknowledges, the alert has already been routed away from the rota engineer. The escalation policy falls through to the next region, which is asleep and has no context, or it stops.
- Overrides multiply. A holiday now needs an override on the regional roster and possibly a change to the routing rule. The person covering may be in a different region with different hours.
None of these are fatal individually. Together they mean the setup needs a maintainer. The maintainer usually finds out about a problem when a page is missed.
How are gaps and weekends handled in a follow the sun rotation?
Handle gaps by deciding in advance what happens when nobody is on shift. Treat weekends as gap hours rather than pretending weekday shifts cover them.
Two reasonable behaviours for a gap:
- Page the rota engineer immediately. The rotation behaves like a normal one. This fits services where minutes matter and gaps are short.
- Nudge, then page. Post to a default channel with a shorter wait, then page the rota engineer. This works for services where a few minutes of delay is acceptable and the team has people who check Slack outside their shift.
Weekends are the largest gap and the one most often left implicit. Weekend cover is the rotation’s job. The rota engineer is on call at the weekend as they would be without follow the sun. Shifts only reduce their load during the week. Teams that want weekend follow the sun add weekend shifts with their own members. This is a staffing decision rather than a scheduling one.
Critical alerts deserve their own rule. A five-minute nudge before paging the accountable engineer may be an acceptable trade for some alerts, but not for a customer-facing outage. A per-roster switch that lets critical-severity alerts bypass the nudge keeps the decision in one place.
How does AlertKick model follow the sun?
As a schedule type on the roster, chosen at creation, with the alerting algorithm doing the timezone work at page time instead of routing rules doing it in advance.
The rotation stays a plain daily or weekly rota with the same overrides, swaps, timeline and iCal feeds as any other roster. On top of it, the roster has shifts. Each shift has its own timezone, start and end time (overnight is fine), days of the week, members and Slack channel. The 3-region example above is three shifts on one roster:
roster: global-primary (follow the sun, weekly rotation, Monday 09:00 UTC)
shifts:
APAC Australia/Sydney 09:00-17:00 Mon-Fri #oncall-apac
EMEA Europe/London 09:00-17:00 Mon-Fri #oncall-emea
AMER America/New_York 09:00-17:00 Mon-Fri #oncall-amer
gap hours: nudge default channel, wait 2 min, then page
critical: bypass nudge, page immediately
Because each shift carries its own IANA timezone, daylight saving is handled per shift. The 24-hour coverage strip in the roster editor shows the resulting handovers and gaps in your own local time, and the schedule timeline shows each shift’s working window as a tinted band behind the rotation bars.
When an escalation policy level targets a follow-the-sun roster, the algorithm checks one thing before paging: is the rota engineer inside their shift right now?
- Yes. They are paged normally. Nothing is different from a plain roster.
- No, and another shift is on. The alert is posted to the awake shift’s Slack channel with an Acknowledge button and a plain statement that the rota engineer will be paged in five minutes (the default wait) unless someone takes it. One click acknowledges the alert everywhere and the page never fires. No click, and the rota engineer is paged exactly as the policy says.
- No, and no shift is on. The per-roster gap setting applies: page immediately, or nudge the roster’s default channel with a shorter wait (two minutes by default) and a message saying that nobody is in working hours.
Overrides page directly, because an override is someone deliberately taking the shift. Critical alerts can bypass the nudge per roster. Every nudge is recorded on the alert timeline: which channel was nudged, how long the wait was, and whether the page fired or was acknowledged away.
The effect is that the regional rosters, the routing rules and the ownership problem all collapse into one roster that a single person can read. The rota engineer is still the backstop, so an alert never goes unowned; the awake region simply gets the first chance to take it.
How AlertKick handles this
Follow the Sun is a roster schedule type in AlertKick. Shifts are defined per region with their own timezone and Slack channel. The nudge-then-page algorithm uses a configurable wait. Gap hours are explicit. Critical alerts bypass the nudge. Every event is recorded on the alert timeline.
Alerts arrive from Prometheus Alertmanager, Grafana, Datadog, CloudWatch, Zabbix, Nagios and more than twenty other sources. AlertKick sits as the on-call layer over existing monitoring. On-call rosters and escalation policies are included on every plan, including Free. See the Follow the Sun feature page and on-call features.
Frequently asked questions
- What is follow the sun on-call?
- Follow the sun on-call is an arrangement where responsibility for alerts moves around the globe with the working day, so that the engineers who are awake and at their desks handle alerts instead of a colleague being woken in another timezone. It requires a team with real timezone spread, typically two or three regions eight hours apart, and it works alongside a normal rotation rather than replacing it.
- When does follow the sun on-call make sense?
- When the team has engineers in at least two regions whose working hours cover a meaningful slice of the day the other region does not, and when those engineers can genuinely act on each other's alerts. A team clustered within two or three hours of each other gains nothing from it. A team split between Europe and Australia, or across three regions, gains most of the night back.
- How is follow the sun on-call usually implemented?
- The classic approach is one on-call schedule per region, layered so the active region's schedule takes precedence, combined with time-of-day routing rules that send alerts to the right layer. It works, but daylight saving changes shift the boundaries, gaps appear at weekends and handovers, and ownership of the routing rules is unclear because they live outside any single schedule.
- How are gap hours handled in a follow the sun rotation?
- Gap hours are periods when no region is on shift, most commonly weekends and the hours between one region ending and the next starting. They should be explicit. The options are to page the rota engineer immediately as a normal rotation would, or to attempt a nudge to a default channel with a short wait before paging. Either way the behaviour must be chosen deliberately, not left as an accidental hole.
- Does follow the sun replace the on-call rotation?
- No. Someone still needs to be accountable for the alert if nobody in the awake region picks it up, and that person is the rota engineer. Follow the sun changes who is asked first, not who is ultimately responsible. The rotation, overrides, swaps and calendar feeds stay exactly as they were.
- How does AlertKick implement follow the sun?
- As a roster schedule type chosen at creation. The rotation stays a plain daily or weekly rota, and you add shifts, each with its own timezone, hours, days, members and Slack channel. When an alert targets the roster and the rota engineer is outside their shift, the awake shift's Slack channel gets a nudge with an Acknowledge button, and the rota engineer is paged only if nobody acknowledges within the wait, which defaults to five minutes. Gap-hour behaviour and a critical-alert bypass are per-roster settings.
