On-Call Schedule Examples for Teams of Every Size
There is no single best on-call schedule. There are patterns that suit particular team sizes, locations and paging volumes. Here are five, with the trade-offs of each.
An on-call schedule turns a list of people into a timetable of responsibility. The right pattern depends on how often you are paged, how many people you have, whether you span time zones and what your people can sustain. The five patterns below cover most teams. Each is described in terms that map directly to schedule layers, so that it can be built in any tool that supports them.
Pattern 1: A simple weekly rotation
One rotation, one person at a time, changing weekly at a fixed hour. This is the starting point for a small team that is paged occasionally.
Strengths: easy to understand, few handovers. Weaknesses: a week is a long time if the pager is busy, and the person on call cannot plan their evenings. If the team is small, each person's turn comes round often, so check that the cycle is sustainable. Choose a handover time during working hours, when the outgoing and incoming person are both awake, rather than at midnight.
Pattern 2: Primary and secondary
Two people are on call together: a primary who is paged first and a secondary who is paged if the primary does not answer. Build it as two schedules, or two steps in an escalation policy, each pointing at a rotation.
Strengths: a failure to answer by one person does not leave the system unattended, and the secondary learns the role. Weaknesses: it doubles the number of people committed, so it needs a larger team. A good variant offsets the two rotations so that the person who was primary last week is secondary this week. They carry fresh knowledge of what is happening.
Pattern 3: Weekday and weekend layers
A weekday rotation covers working days and a separate weekend rotation covers Saturday and Sunday. Some teams give weekends to volunteers, rotated among them, who are compensated for the more intrusive duty.
In Atlas, layers stack and a later layer wins where it applies, so a weekend layer can sit over a weekday layer within one schedule. That is better than two schedules, because someone must remember to update both. Check the boundary at the start of Saturday and the end of Sunday in your schedule's own time zone.
Pattern 4: Follow the sun
Teams in several regions hand the pager from one to the next as the working day moves around the world, so that no one is on call at night. A team in Europe covers its daytime, then hands to a team in the Americas, then to one in Asia.
Strengths: nobody is woken routinely. Weaknesses: it needs enough people in each region, and handovers carry more risk because the people are far apart in time and context. Write handovers carefully and overlap shifts briefly so that the outgoing team can answer questions. Define each region's window in its own IANA time zone so daylight-saving changes in one region do not leave a gap.
Pattern 5: Business hours plus a thin out-of-hours layer
During working hours the whole team shares the load through normal channels. Outside those hours, a small rotation covers only severe incidents. Configure the out-of-hours layer to be paged only for the highest severity levels.
Strengths: it matches the cost of interruption to the value at risk, and most pages happen when people are at work. Weaknesses: it relies on a clear severity scale. If everything is severe, out-of-hours duty is heavy. See the severity levels guide.
Checks for any pattern
- Is every hour covered? Look at the next fourteen days for uncovered stretches. Atlas draws these in the band on the On call page.
- Does each handover happen at a sensible time in the zone of the people involved?
- Does the schedule hold across a daylight-saving change?
- Is the load shared fairly across a quarter, not only across a month?
- Is there a fallback if the person on call does not answer?
- Have you simulated the escalation after the last change?