Three questions that decide the rotation
- When does the service need a human? A customer-facing API sold with an uptime commitment needs round-the-clock coverage. An internal reporting tool may only need business hours.
- How many people can share the load? Rotation length and frequency follow from the number of engineers who can realistically respond to this service.
- Where are they? One office, two time zones or three continents lead to very different schedules.
A benchmark from Google SRE
The Google SRE book, in its chapter on being on-call, sets limits that many teams use as a reference. It caps on-call time at 25 percent of an SRE's working time, and suggests that a single-site team running a primary and secondary rotation needs at least eight engineers to stay within that, or six per site for a team split across two sites. It also treats two incidents per 12-hour shift as the maximum a responder can handle properly, including follow-up and the postmortem. You do not have to match these numbers, but if your rotation is far from them, expect fatigue.
1. Weekly rotation with primary and secondary
Each engineer is primary for one week, then secondary the week after or later in the cycle. Handover happens on a fixed weekday and time, usually mid-morning on a working day so both people are awake and at work.
- Good for: most product teams with five to ten engineers who can respond.
- Watch for: a quiet week and a rough week feel very different. Track on-call load per person so the unlucky ones get relief.
2. Daily rotation
The pager moves every day. Each engineer is on call more often but for shorter stretches.
- Good for: teams where nights are busy, so no one should carry a full week of broken sleep.
- Watch for: more handovers mean more chances to drop context. Keep a short written handover note.
3. Split week between weekdays and weekends
One person covers Monday to Friday, another covers the weekend, often from Friday evening to Monday morning.
- Good for: teams that want to spread weekends fairly and let people plan their private life.
- Watch for: weekend shifts are the least popular, so rotate them strictly and consider compensation or time off in lieu.
4. Day and night shifts in one time zone
The day is split into two 12-hour shifts, for example 08:00 to 20:00 and 20:00 to 08:00, each with its own rotation.
- Good for: services with frequent pages at all hours and a team large enough to staff two rotations.
- Watch for: night shifts without reduced daytime work lead to exhaustion. Night on-call should come with lighter project work.
5. Follow-the-sun
Two or three teams in different regions each cover their daytime hours, and the pager passes from region to region as the working day moves around the globe.
| Region | Local hours covered | Hands over to |
|---|---|---|
| Asia Pacific | 09:00 to 17:00 local | Europe |
| Europe | 09:00 to 17:00 local | Americas |
| Americas | 09:00 to 17:00 local | Asia Pacific |
- Good for: distributed organisations. Nobody is paged at night during a normal week.
- Watch for: handovers are the risk. Hours between regions rarely line up exactly, so define who covers the gaps and hand over open incidents in writing.
6. Shadow and reverse shadow
A new engineer shadows the primary for one or two cycles and receives the same pages without being responsible. Then they switch: the new engineer is primary and the experienced engineer is the backup.
- Good for: onboarding anyone into an existing rotation. It combines well with any of the patterns above.
- Watch for: the shadow must be added to the schedule itself, not just invited informally, so they actually receive the pages.
On-call rotation patterns compared
| Pattern | Minimum practical team | Night pages for one person | Best fit |
|---|---|---|---|
| Weekly primary and secondary | 5 to 8 engineers | Up to a week at a time | Most product teams |
| Daily | 5 or more engineers | One night at a time | Services with noisy nights |
| Split week | 4 or more engineers | Weekend blocks | Teams that value predictable weekends |
| Day and night shifts | 8 or more engineers | Night shift only | High page volume around the clock |
| Follow-the-sun | 2 to 3 regional teams | Rare | Distributed organisations |
| Shadow and reverse shadow | Any | Same as the base pattern | Onboarding |
What keeps on-call fair and healthy
- Always have a secondary. A single tier with no fallback means a silent phone equals an unanswered page. Your escalation policy should move to the secondary after a fixed timeout.
- Make swaps and overrides easy. People get sick and go on holiday. If changing the schedule takes a ticket, people swap informally and the schedule stops matching reality.
- Hand over at a sensible hour. Mid-morning on a working day, never late on a Friday.
- Measure the load. Count pages per shift, pages outside working hours and time spent on incidents per person. Tune alerts before adding people.
- Reduce noise first. Group and deduplicate alerts so one failure produces one page, and use maintenance windows during known work.
- Compensate on-call. Whether through pay, time off in lieu or reduced project work, carrying the pager is work and should be treated as such.
For the escalation side of the design, read our guide on escalation policy, and to see how rotations fit the rest of the response, the incident response playbook.
Every pattern above, in one scheduler
IncidentBot supports weekly, daily, split and custom rotations, follow-the-sun handovers, overrides and swaps, calendar sync, and escalation policies with tiers and timeouts. Pages go out by push, SMS, voice, email and Slack, and the on-call load report shows who is carrying too much. Schedules and escalation policies can be imported from Opsgenie and PagerDuty. See the details on the on-call scheduling software page, compare plans on the pricing page, or try an escalation path in the incident simulator.