On-call rotation: types, schedules and how to design a fair one

An on-call rotation is a schedule that assigns responsibility for responding to alerts to one person (or a primary and a backup) at a time, on a repeating cycle. The two decisions that matter most are the rotation length — how often the on-call person changes — and the escalation path for when that person doesn’t respond. Everything else in this guide is detail on top of those two choices.

What an on-call rotation actually schedules

A rotation doesn’t schedule work — it schedules who gets interrupted when an alert source fires. The person on-call carries a pager (in practice, today, usually a phone) for their shift and is expected to acknowledge and start triaging an incident within an agreed window. When they don’t, an escalation policy moves the alert to the next tier — typically a secondary responder, then a manager, then a wider fallback.

Rotations sit on top of schedules, and schedules sit on top of teams. A team owns a schedule; a schedule generates a rotation of who is on-call at any given minute; an escalation policy decides what happens when the person the schedule names doesn’t answer. Getting the rotation right matters because a badly designed one either burns people out or leaves gaps nobody notices until an alert goes unanswered — the start of the incident’s response process.

Rotation types

Most teams use one of a handful of well-understood patterns, sometimes layered together. There is no universally “correct” one — the right pattern depends on team size, time zone spread and how much interruption a shift realistically costs.

Weekly rotation

The most common pattern for small and mid-sized teams: one person is on-call for a full week, then hands off to the next person in the roster. A week is long enough that everyone knows in advance when their turn is coming, and short enough that a bad week doesn’t drag on. The main risk is fatigue if the alert volume is high and the same day-of-week keeps landing on the same person as the roster cycles.

Daily rotation

The on-call person changes every 24 hours, usually at a fixed handoff time (09:00 local, for example). Daily rotations spread interruption load more thinly across more people, which suits teams with heavy alert volume or teams that want every engineer to stay in practice without carrying the pager for a whole week. The trade-off is more handoffs, and more chances for a handoff to be missed.

Follow-the-sun

Used by teams with engineers spread across time zones: the on-call responsibility moves to whichever region is currently in business hours, so nobody is ever paged in the middle of their own night. A three-region follow-the-sun setup (e.g. US, EMEA, APAC) typically has each region on-call for roughly eight hours before handing off to the next. It only works if each region has enough people to sustain its own rotation — a single engineer “covering” a region alone isn’t follow-the-sun, it’s just that engineer working nights.

Primary / secondary

Not a rotation length but a layering pattern: two people are on-call at once, a primary who gets paged first and a secondary who is the automatic backstop if the primary doesn’t acknowledge in time. This is less a separate rotation type than a way of adding redundancy to any of the patterns above — you can run a weekly primary/secondary rotation, a daily one, or a follow-the-sun one with a secondary in each region.

Business hours plus after-hours

Some teams split coverage into two named rotations: one roster covers 09:00–18:00 on business days (often just whoever is working that day, with no special pager), and a separate, smaller after-hours roster covers nights, weekends and holidays. This reduces the after-hours roster to the people willing to take that shift, rather than putting the whole team through night pages.

Layers and overrides

A single flat list of names rotating in order works for a small team, but most schedules end up needing two more concepts:

• Layers. A schedule can stack multiple layers — for example, a base weekly rotation layer plus a narrower layer that only covers weeknights, restricting a subset of the roster to a subset of the time. Layers combine to produce the final answer to “who is on-call right now.”
• Overrides. A single, temporary change that sits above every layer — one person covering a named day or hour for someone else, without editing the underlying rotation. Overrides are how a swap for a doctor’s appointment or a one-off vacation day gets handled without restructuring the whole schedule.

Restricting a layer to a time window (weekdays only, business hours only, nights only) is what makes business-hours-plus-after-hours and follow-the-sun schedules practical to build without hand-maintaining a separate calendar.

Handoffs

The handoff — the moment responsibility passes from one on-call person to the next — is where rotations quietly fail. Two practices prevent most handoff problems:

• Fix the handoff time, and make it boring. Handing off at 09:00 on a weekday, rather than at midnight or mid-incident, means the outgoing person is awake and reachable if the incoming person has a question about something still in progress.
• Hand off state, not just responsibility. Any open incident, any known-flaky alert, any maintenance window in progress should be visible to the incoming on-call person before they take the pager, not discovered the hard way.

Confirm the outgoing person’s last acknowledged incident is closed or explicitly hand it over — a handoff mid-incident is the single most common way an incident gets dropped between two people who each assume the other has it.

Time zones and DST pitfalls

Schedules should be defined in a named time zone (e.g. America/New_York), never a fixed UTC offset. A fixed-offset schedule silently shifts by an hour every time the underlying zone observes daylight saving time, so a handoff meant for 09:00 local drifts to 08:00 or 10:00 twice a year until someone notices.

The pitfalls worth checking for explicitly:

• The DST transition itself. On the day clocks change, a schedule defined in local time either has a 23-hour or a 25-hour day. If a rotation layer is restricted to a fixed hour range (“22:00 to 07:00”), confirm the schedule engine re-derives that range in local time on the transition day rather than freezing the UTC instant it last computed.
• Follow-the-sun regions on different DST calendars. The US and EU observe daylight saving on different dates, so a follow-the-sun handoff time that’s exactly 8 hours apart in January can be 7 or 9 hours apart for a few weeks in March and October.
• Reporting and audits in UTC, humans in local time. Keep the stored record of who was on-call in UTC (so it never moves), but always display it to a human in their own local time. Mixing the two in one screen is the most common source of “who was actually on-call” disputes.

Fairness and time off

A rotation that looks fair on paper — everyone gets an equal number of weeks — can still be unfair in practice if the same person always lands on the weeks with the most alerts, or always gets the holiday week. A few practical rules keep it fair over time:

• Rotate the starting order periodically so the same person doesn’t always draw the same calendar weeks year over year.
• Track actual interruption load (pages received, not just shifts served) alongside the roster, so a quiet week and a brutal week both count as “a week,” even though they cost very different amounts — persistently high interruption load on the same shifts is a sign of alert fatigue building up, not just bad luck.
• Let people request time off from the rotation in advance, and have a clear swap process (with approval) for last-minute conflicts, rather than an informal side channel nobody can audit later.
• Keep after-hours rosters smaller and better compensated (in time or pay) than business-hours coverage, since the interruption cost is higher.

Example schedules

These are examples to adapt, not a template you need to copy exactly.

4-person team — weekly rotation with secondary

Four people, each on primary one week in four and secondary the week before their own primary week — so everyone is already “warm” on the rotation state when their primary week starts.

6-person team — business hours plus a smaller after-hours roster

12-person team — follow-the-sun across three regions

Each region hands off at its own local business-hours boundary, so the pager always lands on someone currently awake and working.

On-call rotation checklist

• Schedule is defined in a named IANA time zone, not a fixed UTC offset.
• Handoff time is fixed, documented and falls inside normal working hours for the outgoing person.
• Every rotation layer has a documented fallback if the named person doesn’t answer.
• Overrides and approved swaps are visible to the whole team, not tracked in a side channel.
• Time off requests are captured before the schedule generates, not worked around after the fact.
• After-hours coverage is a smaller, separate roster from business-hours coverage.
• Someone reviews interruption load (not just shift count) periodically to catch an unfair rotation early.
• The DST transition dates are checked at least once a year against every layer’s time restrictions.

How CallHeim handles this

Teams with member rosters own schedules and link to escalation policies. Schedules use any IANA time zone.

Schedules support layers, an override that sits above the layers, layer restrictions to weekdays, business hours or nights, follow-the-sun templates, time off, shift-swap requests with approval, and coverage-gap detection with suggested fills. Coverage gaps are shown in the console; they are not alerted in advance.

A published on-call fatigue score: 0.40 sleep-window interruptions, 0.30 volume, 0.20 off-hours, 0.10 severity, over a rolling 14 days. It is a heuristic over your own paging history, not a wellbeing measure.

Rotations are one piece of the wider on-call workflow — see our complete guide to on-call software for how scheduling, escalation and alerting fit together.

Key takeaways

• Pick a rotation length (weekly, daily, follow-the-sun, or a business-hours/after-hours split) that matches your team’s size and time zone spread.
• Layers and overrides let one schedule express business-hours restrictions, follow-the-sun handoffs and one-off swaps without hand-editing a roster.
• Fixed, boring handoff times prevent more incidents from falling through the cracks than any amount of documentation.
• Always schedule in a named time zone — DST silently breaks fixed-offset schedules twice a year.
• Fairness means tracking interruption load, not just counting shifts.