How to create an on-call schedule: rotation length, handovers and examples
An on-call schedule is a rotation length, a handover time, a timezone and an ordered list of people. How to choose each, with example schedules for 3, 5 and 8 people.
Sandeep Sidhu · Founder, AlertKick
To create an on-call schedule, pick a rotation length (weekly is the default that suits most services), choose a handover day and time in the team’s working timezone (a weekday morning, never Friday or midnight), and order the people in the rotation. Put the schedule in a tool that computes the handovers from an IANA timezone, preview the next few months before publishing, and share it as a calendar feed. Add a secondary once there are enough people, and handle holidays with overrides rather than by editing the rotation.
Each step has a decision inside it, and those decisions are where schedules go wrong: a rotation too long for the alert volume, a handover when neither engineer is awake, a timezone that moves with daylight saving, a spreadsheet nobody updates after the first swap. This post walks through the time side of the schedule in order. Who belongs on the rota is covered in the on-call roster guide; what happens to an alert once the schedule has named a person is in what is an escalation policy.
What is an on-call schedule?
An on-call schedule maps any moment in time to the person responsible for responding to alerts. It is built from four parts: an ordered list of people, a rotation length, a handover day and time, and a timezone.
The words get used loosely, so a quick definition of each:
- Roster: the ordered list of people, plus the rotation rule. The thing you configure.
- Rotation: the rule that advances the pointer from one person to the next: daily, weekly, every two weeks.
- Schedule: the resulting calendar of who is on-call when, which is what everyone else looks at.
Changing the rotation changes every future shift. An override changes one date range and leaves the rotation alone.
How long should each on-call rotation be?
One week is the right default for most services. Daily suits high-volume services or shift-based coverage; two weeks suits services that rarely page.
The rotation length is a trade-off between how often people hand over and how long a bad week lasts.
| Rotation length | Handovers per person per cycle | Best for | Watch out for |
|---|---|---|---|
| Daily | 1 per day | High alert volume, follow-the-sun shifts, primary/secondary flip | Context is lost at every handover; weekends need explicit handling |
| Weekly | 1 per week | Most services, most teams | A noisy week is a whole week; make sure the alert volume is sustainable |
| Two-weekly | 1 per fortnight | Quiet services, teams who want fewer handovers | A bad fortnight is a bad fortnight; holidays overlap a whole shift more often |
| Custom | Varies | Weekday-only cover, weekend-only groups, irregular patterns | Harder to reason about; preview before publishing |
Weekly wins for most services because it lines up with how people plan their lives: on-call for a week, off for two or more, with the boundary on a working day so the handover can be a conversation. It is also long enough that whoever is on-call learns the current state of the system, which a daily rotation never gives them.
Daily rotations earn their place where the alert load is high enough that a week would be unreasonable, or where the schedule is built from shifts: a 12-hour primary/secondary flip, or regional cover that follows the working day around the globe. If the rotation is daily because of timezones, a follow-the-sun schedule is usually the cleaner model.
Two-week rotations halve the handovers, but everything else doubles too: the length of a bad stretch, the chance a holiday collides with a shift, the gap between turns during which people forget the runbook. Reserve it for services that page rarely. Most tools let you rotate every N days or weeks, so “weekly, rotate every 2” gets the fortnightly pattern without a separate schedule type.
When should the on-call handover happen?
A weekday morning, at the start of the team’s working day, in the roster’s timezone. Monday or Tuesday at 09:00 or 10:00 is the usual answer.
The handover moment has three jobs, and the time you pick should let all three happen:
- Both people are awake and at work. The outgoing engineer can say what is currently noisy, what was fixed at the weekend, and what to watch. A handover at midnight is a handover with no conversation.
- Overnight incidents have settled. An alert that started at 03:00 on the final night is in a known state by 09:00 and can be handed over as a fact, not a mystery.
- The new person has a full working day before their first night. Handing over at 17:00 sends someone straight into their first night on-call with no chance to look at the dashboards.
Monday versus Tuesday is mostly about weekends: Monday means the outgoing engineer hands over whatever happened at the weekend; Tuesday gives the team Monday to settle weekend fallout first. Both work; pick one and keep it. Friday is the wrong day, because the incoming engineer’s first two days are the weekend with no colleagues around.
Which timezone should the schedule use?
Use one IANA timezone for the roster, set to where the majority of the rotation works, and let everyone view the schedule in their own local time.
Spreadsheets get timezones wrong quietly. A handover written as “09:00” with no zone is ambiguous the first time someone in another region joins the rota. A handover stored as a UTC offset is wrong twice a year when daylight saving changes.
Store the handover against a named zone such as Europe/London or America/Denver. The handover stays at 09:00 local in that zone all year. People in other zones see it shift by an hour when their clocks change relative to the roster’s. That is the intended behaviour: the handover should happen at the start of the working day where the on-call engineer is.
When the team is spread across regions, a single weekly rotation fails. Someone is on-call through their night while colleagues elsewhere are awake. The schedule should become a follow-the-sun arrangement with per-region shifts, not a longer rotation. The follow-the-sun feature page describes how AlertKick models that as a schedule type.
Should the schedule have a primary and a secondary?
Yes, as soon as the rotation has enough people. The secondary is who the escalation policy pages when the primary does not acknowledge, and it turns “the on-call missed the page” from an outage into a delay.
There are two ways to build a secondary:
- Offset roster. Two rosters with the same members, rotation and handover, with the member order shifted by one position. Works for any rotation length.
- Last week’s primary. The secondary is the person who was primary last week. They have the freshest context and are already winding down from the pager. This is an offset roster in the opposite direction, and the better default for weekly rotations.
The escalation policy then points level 1 at the primary roster and a later level at the secondary roster. On a three-person rota each person carries some responsibility two weeks in three, so the secondary should only be paged after a genuine wait. Do not model the secondary as “everyone else”: a page that goes to the whole team goes to nobody in particular.
What does an on-call schedule look like for 3, 5 or 8 people?
The shape changes with the headcount. Three people is a tight single tier. Five people supports a primary and secondary. Eight people is the point to split by service.
Three people, weekly, single tier
| Week | Primary | Secondary |
|---|---|---|
| 1 | Alex | Casey |
| 2 | Blake | Alex |
| 3 | Casey | Blake |
| 4 | Alex | Casey |
Each person is primary one week in three and secondary the week after. Two weeks in three carry some responsibility, so the secondary level in the escalation policy should have a generous wait and be understood as a backstop, not a co-pilot. Holiday cover on a three-person rota means the other two alternate; that is survivable for a week and not for a month.
Five people, weekly, primary and secondary
| Week | Primary | Secondary |
|---|---|---|
| 1 | Alex | Emery |
| 2 | Blake | Alex |
| 3 | Casey | Blake |
| 4 | Drew | Casey |
| 5 | Emery | Drew |
Primary one week in five, secondary the following week, three weeks completely off. This is the size at which a rotation stops feeling like a burden and holidays can be absorbed with a single override. It is also the size at which the secondary can be paged with confidence, because being secondary is not a second shift.
Eight people, weekly, two services
| Week | Platform primary | Platform secondary | App primary | App secondary |
|---|---|---|---|---|
| 1 | Alex | Drew | Emery | Harper |
| 2 | Blake | Alex | Finley | Emery |
| 3 | Casey | Blake | Gray | Finley |
| 4 | Drew | Casey | Harper | Gray |
Eight people in one rotation means each person is on-call one week in eight, which sounds generous until the week arrives and nobody remembers what changed in the previous seven. Splitting into two four-person rosters keeps each rota familiar with its own service. The escalation policy for platform alerts points at the platform roster; the app policy points at the app roster. If the eight people genuinely share one service, an eight-person rotation with an offset secondary still works; it just needs a deliberate handover to carry context across the seven-week gap.
How should the schedule be shared with the team?
Publish it as a calendar feed and let people subscribe. A schedule that lives only inside the on-call tool, or worse in a spreadsheet, is a schedule nobody checks.
Calendar feeds solve two problems at once. Each person sees their own shifts next to the rest of their life, which is when holidays get noticed early enough to arrange a swap. The feed updates itself when an override is added, which a screenshot in a Slack pin never does. The practical setup is one feed per roster for the team view, and one per person containing only their shifts.
Before publishing, look at the next three months rendered as a timeline. If the blocks do not alternate the way you expected, the member order is usually the thing to fix, not the rotation settings. Anyone outside the roster’s zone should check the handover in their local time once, so “09:00” does not turn out to mean 01:00.
When should an on-call schedule change?
Change the rotation when the team or the service changes. Handle everything else with overrides, and leave the rotation alone.
Every edit to the rotation reshuffles the future for everyone. An override changes one date range and the rotation resumes untouched afterwards. A swap is a paired override: two people trade a shift, and nothing else moves.
| Situation | Change the rotation? | Use instead |
|---|---|---|
| Someone is on holiday next week | No | Override for the date range |
| Two people want to trade weeks | No | Swap (paired override) |
| Someone is sick mid-shift | No | Override from now until the next handover |
| A new person joins the team | Yes | Add them to the roster; they enter at the next cycle |
| Someone leaves | Yes | Remove them; the next handover skips to the following person |
| The service is much noisier than it was | Maybe | Shorten the rotation, or fix the alerts first |
| The team has grown past 7 or 8 | Yes | Split into rosters by service |
Review the rotation length occasionally against real data: pages per shift, how often the secondary was actually paged, how many overrides were needed last quarter. If overrides are constant, the rotation is fighting how people work. The review discipline is covered in on-call rotation best practices.
How AlertKick handles this
AlertKick rosters are an ordered list of members plus a rotation: daily, weekly or custom, with “rotate every N” days or weeks, an IANA timezone per roster, and a handover day and time. The editor shows a timeline preview before you save, viewable in your own timezone. Overrides are layered on the rotation for a date range and the rotation resumes untouched afterwards; swaps are paired overrides. Every roster and every user has an iCal feed for Google, Apple and Outlook calendars, and a Follow the Sun schedule type adds per-region shifts for teams spread across timezones. Escalation policies page the current on-call from a roster so the schedule, not the policy, decides who gets woken. Rosters, schedules and escalation are included on every plan including Free, and pricing is by infrastructure rather than per seat, so the whole team is on the rota at no extra cost; details are on the on-call feature page and in the roster management guide.
Frequently asked questions
- How do you create an on-call schedule?
- Decide the rotation length (weekly is the usual default), the handover day and time (a weekday morning in the team's working timezone), and the order of people. Set the schedule in a tool that computes handovers from an IANA timezone, preview the next few months, and publish it to everyone's calendar. Then layer overrides for holidays rather than editing the rotation itself.
- How long should an on-call rotation be?
- One week is the standard for most services because it gives a clean boundary, one handover per person per cycle, and enough time to learn the current state of the system. Daily shifts suit high-volume services and follow-the-sun coverage. Two-week rotations reduce handovers but make a bad week twice as long, so they are best kept for services that rarely page.
- What is the best day and time for an on-call handover?
- A weekday morning at the start of the team's working day, typically Monday or Tuesday at 09:00 or 10:00 in the roster's timezone. Both engineers are awake and at work, the outgoing person can hand over context, and any incident that started overnight is settled before responsibility moves. Avoid Friday and avoid midnight.
- How many people do you need for an on-call schedule?
- Three is the practical floor for a single-tier rotation: each person is on-call one week in three. Two people means alternating weeks with no cover for holidays or sickness. Five to six people gives a comfortable cycle and enough spare capacity to run a secondary. Above eight, consider splitting by service so each rotation stays familiar.
- Should an on-call schedule have a primary and a secondary?
- Yes, once the rotation has enough people to support it. The secondary is who the escalation policy pages when the primary does not acknowledge. A simple way to build one is to make the secondary the person who was primary last week, since they still have the most context. With five or more people it is usually cleaner as a separate roster offset by one position.
- How do you handle timezones in an on-call schedule?
- Store the schedule against a single IANA timezone such as Europe/London, compute every handover in that zone, and let each person view the schedule in their own timezone. Daylight saving changes then shift the handover in other regions rather than breaking it. For teams spread across several regions, a follow-the-sun schedule with per-region shifts is a better model than one long rotation.
- How do you share an on-call schedule with the team?
- Publish it as an iCal feed that people subscribe to from Google, Apple or Outlook calendars, one feed per roster for the team view and one per user for personal shifts. A subscribed feed updates itself when overrides are added, which a screenshot or spreadsheet never does.
