On-Call Rotation Guide: Schedules, Handoffs & Templates

What's in this guide

• The coverage math: how many engineers you need before a rotation is sustainable
• Daily, weekly and follow-the-sun rotations, and who each one is actually for
• Primary and secondary, with two worked examples
• A 2-minute handoff checklist and a handoff message you can paste into Slack
• Overrides, fairness and on-call pay
• Three copy-paste schedule templates, plus the same rotation expressed as code
• How to tell whether the rotation is working, in five numbers

There are two ways to find out that your on-call rotation is broken. The first is a quiet Tuesday when somebody notices the schedule ran out three weeks ago and nobody has technically been on call since. The second is a Saturday at 04:12, when the alert fires, the primary is at a wedding with their phone face down, and there is no secondary because the person who built the schedule assumed there would always be someone around.

Most rotations are not designed. They accrete. Someone volunteers, someone else covers, a shared calendar appears, and eighteen months later the arrangement is load-bearing and nobody can say out loud who is responsible at 4 a.m. on a public holiday.

This guide is the design version. It covers the decisions in the order you actually have to make them, and it ends with templates you can paste and edit rather than admire.

First, the coverage math

Before you pick a pattern, work out whether you have the people for one. This is the question every guide skips and every engineering lead asks first.

A rotation is sustainable when the person on call can have a normal week. The arithmetic is unglamorous:

• With 4 engineers on a weekly rotation, everyone is on call 13 weeks a year. That is one week in four, every month, forever. It works, but there is no slack in it. One resignation and you are at one week in three.
• With 6 engineers, it is roughly 8 weeks a year. This is the first point where a rotation stops feeling like a tax.
• With 8 or more, it is 6 weeks a year or fewer, and you can run a proper secondary tier without the same people covering both.
• Below 4, you do not have a rotation. You have two people taking turns, and you should be honest about that when you write it down, because the failure mode is both of them being unavailable at once.

The second number is out-of-hours load. Count how many pages actually fired outside business hours over the last quarter and divide by the number of shifts. If a typical shift wakes someone up more than once, the rotation is not your problem and no schedule will fix it. Fix the alerts first: tune the thresholds, delete the ones nobody has acted on in six months, and read up on alert fatigue before you spend a week designing a rota that distributes suffering more evenly.

The third is the honest one. A rotation only works if being on call is a real assignment, not something layered on top of a full sprint commitment. If the on-call engineer is still expected to land their tickets that week, you have not created a rotation, you have created a person who will resent it.

What a rotation actually is, structurally

Three separate objects, and keeping them separate is most of the battle:

1. The schedule. Who is on duty, when, and in what order. See on-call schedule for the anatomy.
2. The escalation policy. What happens when the person on duty does not answer. Covered in escalation policy.
3. The overrides. Temporary swaps for holidays, sickness and the one Thursday somebody has a flight.

Teams that run rotations on a spreadsheet collapse all three into one grid, which is why the grid always lies eventually. Every serious on-call management software product models them as three separate things for the same reason: they change on completely different timescales. The schedule changes quarterly, the escalation policy changes almost never, and the overrides change weekly.

If you take one structural idea from this guide, take that one. The definition, if you want it in a sentence, is in the on-call rotation glossary entry.

Rotation types: daily, weekly, follow-the-sun

Weekly (the default, and usually right)

One person holds the pager for seven days, handing over at a fixed time on a fixed day. It is the default for a reason: a week is long enough that the on-call engineer builds context on what is currently flaky, and short enough that nobody's life is on hold.

Handover is usually Monday or Wednesday morning, and Wednesday is quietly the better choice. A Monday handover means the incoming engineer inherits everything that happened over the weekend from someone who has just finished a weekend on call and wants to go back to bed. A Wednesday handover puts both the outgoing and incoming engineer at their desks, awake, with the weekend in the middle of one person's shift rather than split across two.

Best for: most teams between 4 and 40 engineers. Trade-off: a bad week is a whole bad week.

Daily

Duty rotates every 24 hours. The load per person per shift is small, and a genuinely awful night is over by morning.

The cost is context. The engineer who took a page at 02:00 hands over at 09:00 to someone who was asleep for all of it, and the investigation restarts from the beginning. Daily rotations create the most handoffs and therefore the most dropped threads, which is why the handoff checklist further down matters more here than anywhere else.

Best for: large teams (roughly 12 or more), high page volume, or a stretch where the system is genuinely unstable and you need to spread the damage. Trade-off: seven times the handoffs of a weekly rotation, and it fragments ownership of any problem that takes more than a day to understand.

Follow-the-sun

Three regional teams roughly eight hours apart, each covering their own working day, so nobody is on call at night. It is the only pattern that actually eliminates the 3 a.m. page rather than sharing it out.

It is also the one most often adopted for the wrong reasons. Follow-the-sun works when you already have real engineering teams in three regions who own overlapping services. It does not work when you have one team in Berlin, two contractors in Singapore, and an aspiration. Below that threshold you get all of the coordination cost (handoffs across time zones, duplicated context, daylight-saving arithmetic that breaks twice a year) and none of the benefit, because the two thin regions escalate everything back to the main team anyway.

If you have the regional teams, the setup is a post of its own: setting up follow-the-sun on-call rotations covers the three-region structure and the daylight-saving trap in detail, and I am not going to repeat it here.

Best for: genuinely distributed orgs with staffed regional teams. Trade-off: the highest coordination cost of the three, and it fails ugly if one region is thin.

Which to pick

Primary and secondary

A single-tier rotation has one failure mode and it is fatal: the primary does not answer. Phones die, tunnels have no signal, people sleep through things. A secondary is not a luxury tier, it is the thing that stops a page from going nowhere.

The primary takes every page first and is expected to acknowledge within a few minutes.

The secondary is paged automatically when the primary does not acknowledge, and is otherwise left alone. Crucially, the secondary is not a second person watching alerts. They should expect to be woken up rarely, and they should be able to plan their week normally.

Two shapes that work:

Example A, an 8-engineer team. Two parallel weekly rotations, offset. In week 1, Ana is primary and Ben is secondary. In week 2, Ben is primary and Chidi is secondary. Everyone does one week of primary and one week of secondary in each cycle, and nobody does both in the same week. That offset is the whole trick, and it is the thing spreadsheets get wrong most often.

Example B, a 5-engineer team. One weekly primary rotation, and a secondary tier that is the engineering manager or the most senior available engineer, on a much slower rotation. This is not fair in the strict sense, and it is still the right call at this size, because the alternative is putting the same five people on two tiers at once.

Behind both sits the escalation rule, which should be boring and written down: primary paged, 5 minutes no acknowledgement, secondary paged, 10 more minutes, the manager. Numbers you can argue about. The principle you cannot: escalation must be automatic. If it requires somebody to notice that nobody has responded, it will not happen at 04:00, which is the only time it matters.

The 2-minute handoff checklist

Every handoff should be written, public, and short enough that nobody skips it. Post it in the team channel rather than sending it as a DM, so that the six people who are not on call can see the state of things without asking.

Six items. If it takes longer than two minutes, you are writing an incident report instead of a handoff:

1. Open incidents. Anything still unresolved, with a link and one line of current status.
2. Watch items. The thing that fired twice on Tuesday and resolved itself. Nobody wants to rediscover it from scratch.
3. Known noise. Alerts that are currently firing for a known reason and can be ignored, with an expiry. Without an expiry this list grows forever and eventually hides a real page.
4. Changes landing. Deploys, migrations or vendor maintenance in the incoming shift's window.
5. Anything suppressed or overridden. If you silenced an alert or put in a maintenance window, say so and say when it ends. This is the single most common cause of a page that never arrives.
6. Anything you would not want to inherit without being told. The catch-all, and the one that usually earns its place.

The handoff message, ready to paste:

ON-CALL HANDOFF
Outgoing: @name        Incoming: @name
Shift: Wed 09:00 -> Wed 09:00

OPEN INCIDENTS
- [INC-1042] Checkout latency, mitigated, root cause open. Owner: @name

WATCH ITEMS
- Payment webhook retries spiked twice Tue night, self-resolved. No ticket yet.

KNOWN NOISE (with expiry)
- disk-usage-warn on build-03: known, box is being replaced. Ignore until Fri.

CHANGES LANDING THIS SHIFT
- Thu 14:00 Postgres minor version upgrade (maintenance window open 14:00-15:00)

SUPPRESSED / OVERRIDDEN
- Alert "queue-depth-high" muted until Thu 12:00

NOTES
- Nothing else. Sleep well.

Two rules about this artifact that are worth more than the artifact itself. The known-noise list must have expiries, or it becomes the place real alerts go to die. And the suppression line is not optional. More post-incident reviews end at "the alert was muted and nobody knew" than at any interesting technical cause.

For anything that needs a fixed procedure rather than a note (a failover, a rollback), that belongs in a runbook and the handoff should link to it. The difference between the two documents is covered in runbook vs playbook.

Overrides, fairness and on-call pay

Overrides

An override is a temporary change to who holds the pager: a holiday, a sick day, a swap because somebody has a flight. They are the most frequent change a rotation ever sees and the one most likely to be handled badly.

Three rules:

Overrides belong in the same system as the schedule. A swap agreed in a DM is not a swap. If the pager still rings the person who is on a plane, the swap did not happen, no matter what anyone agreed. All Quiet has overrides as a first-class object for exactly this reason, and so does every other serious tool.

A swap needs an owner, not a volunteer. "Can anyone cover Thursday?" in a channel produces silence. Name the person, get a yes, put it in the system.

Book known absences a quarter ahead. Holidays are not surprises. If the schedule is built from a rotation rule rather than a hand-typed grid, a booked holiday can be worked around before it becomes an emergency.

Fairness

Fairness in a rotation is measurable, and it is not the same as an equal number of shifts. Equal shift counts still hide unequal pain: weekends, public holidays and the two weeks around a big launch are not equivalent to a quiet week in February.

Track three things per person over a quarter: number of shifts, number of weekend and holiday shifts, and number of pages received. If any of the three is lopsided, the rotation is unfair even if the calendar looks symmetric. The usual culprit is a manual schedule that quietly parks the same person on the same recurring weekend.

Automating the cycle removes most of it. Our own step-by-step is in how to automate fair on-call rotations, which walks through auto-rotation setup and how shifts redistribute when the team changes, so I will not duplicate it here.

On-call pay

Somebody will ask, usually in the same meeting where you propose the rotation. Answer it before it becomes a grievance.

Whether on-call time must be paid depends on jurisdiction and, in most legal frameworks, on how restricted the person is: whether they must stay near a location, how fast they must respond, and how much of their own time is genuinely their own. That test, and the models teams use, are covered in on-call compensation and on our on-call pay page. I am not going to invent benchmark numbers here, because the ones circulating in other guides are unsourced and the range varies enormously by country and company stage.

What is safe to say regardless of jurisdiction:

• Write the policy down before the first shift. Retrofitting compensation after somebody has done six months unpaid is a conversation nobody enjoys.
• Pay for availability, not just for incidents. The cost of on-call is the constrained weekend, not the twenty minutes of typing.
• Time off in lieu is a legitimate model and often the affordable one at an early stage, but only if it is actually taken. Unredeemed TOIL is not compensation, it is a promise.
• If the pay depends on hours held, you need per-shift records. This is the boring argument for having the rotation in a system rather than a spreadsheet: it produces the audit trail by itself.

Schedule templates

Three templates. Copy, edit, delete what you do not need.

Template 1: weekly primary and secondary, 6 engineers

ROTATION: Platform on-call
Pattern:   Weekly, handoff Wednesday 09:00 local
Pool:      Ana, Ben, Chidi, Dee, Eli, Fay
Tiers:     Primary + Secondary (offset by 3)

Week  Primary   Secondary
1     Ana       Dee
2     Ben       Eli
3     Chidi     Fay
4     Dee       Ana
5     Eli       Ben
6     Fay       Chidi
(repeats, 6-week cycle: 1 primary week + 1 secondary week each)

ESCALATION
  0 min   page Primary   (push, then phone call after 2 min)
  5 min   page Secondary (phone call)
 15 min   page Engineering Manager

OVERRIDES
  Booked absences entered at least 2 weeks ahead.
  Same-day sickness: Secondary becomes Primary, EM becomes Secondary.

HANDOFF
  Written in #platform-oncall, 6-point checklist, before 09:30 Wednesday.

Template 2: small team, 4 engineers, no true secondary

ROTATION: Product on-call
Pattern:   Weekly, handoff Wednesday 09:00
Pool:      Ana, Ben, Chidi, Dee
Tiers:     Primary only. Backup = Engineering Manager.

Week  Primary
1     Ana
2     Ben
3     Chidi
4     Dee
(4-week cycle, 13 weeks on call per person per year)

ESCALATION
  0 min   page Primary
  5 min   page Engineering Manager
 15 min   page CTO

CONSTRAINTS (state these openly)
  - On-call week carries a reduced sprint commitment. Non-negotiable.
  - Out-of-hours coverage is best-effort until headcount reaches 6.
  - Review at 6 engineers: introduce a real Secondary tier and drop the EM out.

Template 3: follow-the-sun, three regions

ROTATION: Global on-call
Pattern:   Regional working-day coverage, 3 handoffs per weekday
Regions:   APAC (Sydney) / EMEA (Berlin) / AMER (San Francisco)

Region   Local hours     Handoff to
APAC     09:00-17:00     EMEA at 17:00 local
EMEA     09:00-17:00     AMER at 17:00 local
AMER     09:00-17:00     APAC at 17:00 local

Each region runs its own weekly primary rotation internally.
Weekends: single global weekly rotation, or paid standby. Decide explicitly.

DAYLIGHT SAVING
  Regions shift on different dates. Schedule in local time with a
  timezone-aware tool, never in UTC offsets typed by hand.

HANDOFF
  Written, in the shared channel, at every regional boundary.
  Same 6-point checklist. Non-optional: this pattern has 15 handoffs
  a week and every one is a chance to drop a thread.

A note on how you store these. A spreadsheet is a fine way to design a rotation and a bad way to run one, because the schedule has to be the thing that actually routes the page. In All Quiet the pattern above is a rotation rule rather than a typed grid, so it extends itself indefinitely, redistributes when someone joins or leaves, and can be exported to everyone's personal calendar so nobody has to open the tool to find out whether it is their week. The mechanics are on the rotations and scheduling pages.

Pricing, since it is the next question: All Quiet is $4.99 per user per month on the Standard plan, which includes unlimited SMS, phone calls and push notifications. That is the honest reason we can say "put the escalation policy in a tool" without it being a large ask.

The same rotation, as code

If your infrastructure already lives in a repository, the rotation should too. Template 1 above, the six-engineer weekly primary and secondary with the three-week offset, is this:

  resource "allquiet_team_escalations" "platform" {
  team_id = allquiet_team.platform.id

  escalation_tiers = [
    # Tier 1: primary
    {
      auto_escalation_enabled       = true
      auto_escalation_after_minutes = 5
      schedules = [{
        display_name = "Primary"
        rotation_settings = {
          repeats               = "weekly"
          starts_on_day_of_week = "wed"
        }
        rotations = [
          { members = [{ team_membership_id = allquiet_team_membership.ana.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.ben.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.chidi.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.dee.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.eli.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.fay.id }] },
        ]
      }]
    },
    # Tier 2: secondary, same pool offset by three
    {
      auto_escalation_enabled       = true
      auto_escalation_after_minutes = 10
      schedules = [{
        display_name = "Secondary"
        rotation_settings = {
          repeats               = "weekly"
          starts_on_day_of_week = "wed"
        }
        rotations = [
          { members = [{ team_membership_id = allquiet_team_membership.dee.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.eli.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.fay.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.ana.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.ben.id }] },
          { members = [{ team_membership_id = allquiet_team_membership.chidi.id }] },
        ]
      }]
    },
  ]
}

The offset that spreadsheets get wrong is now a property of the list order, reviewed in a pull request like anything else. Escalation timing sits next to the rotation it belongs to, so the two cannot drift apart, and the diff tells you who changed the on-call structure and when.

Everything in that file is also reachable over the public REST API, which is the part that matters if you want an agent rather than a human to maintain it. That is a longer subject, and we wrote it up separately in AI incident management: the short version is that credentials are scoped per resource, a personal access token can never exceed what its owner can do in the UI, and inference stays on your side because we do not run models on your incident data.

How to tell whether the rotation is working

Build the rotation, then measure it. Five numbers, reviewed once a month:

The one to watch hardest is escalation rate. A rising escalation rate is almost never a discipline problem, and treating it as one is how teams lose engineers. It usually means notifications are not getting through: a phone on silent without a critical-alert override, a push notification that never arrived, an escalation timer set to 30 minutes by someone who has never been paged.

And the number that is not on the list: do not measure a rotation by time to resolve alone. MTTR moves for a dozen reasons that have nothing to do with your schedule, and a rotation that looks good on MTTR while quietly burning out three people is not a rotation that works.

When a spreadsheet stops being enough

To be fair to spreadsheets: for two or three engineers with a handful of alerts, a shared calendar and a group chat genuinely work, and buying a tool to manage four names is procurement theatre.

The threshold is not team size, it is these four:

1. The schedule has to route the page. The moment the rota and the alert routing are separate systems, they drift, and the drift is only discovered during an incident.
2. You need automatic escalation. A human noticing that nobody replied is not an escalation policy.
3. Overrides happen weekly. Hand-editing a grid every week is where mistakes enter.
4. Somebody is asking for on-call records. Pay, audit or a compliance questionnaire. Reconstructing who held the pager last March from calendar history is a bad afternoon.

Hit two of those and a spreadsheet is costing you more than a tool would. All Quiet does the rotation, escalation and override parts of this for $4.99 per user per month, and if you want to see how the category compares before deciding, we keep a comparison of the best on-call tools that includes the ones we lose to.

Frequently Asked Questions

How often should an on-call rotation change?

Weekly is the default and suits most teams. A week is long enough that the on-call engineer keeps context on what is currently unstable, and short enough that it does not take over someone's month. Daily rotations make sense for large teams or high page volume, at the cost of seven handoffs a week instead of one. Monthly rotations are almost always a mistake: too long to sustain and too infrequent to build any rhythm.

How many engineers do you need for an on-call rotation?

Four is the practical minimum for a weekly rotation, which puts each person on call about 13 weeks a year. Six is the point where it stops feeling like a tax, at roughly 8 weeks a year. With fewer than four people you do not really have a rotation, you have two or three people taking turns, and you should plan for the case where both are unavailable at once.

What is the difference between primary and secondary on-call?

The primary receives every page first and is expected to acknowledge within a few minutes. The secondary is paged automatically only when the primary does not respond, and otherwise is left alone. The secondary exists because phones die, signal drops and people sleep through things. It is not a second person monitoring alerts, and it should not be the same person as the primary in the same week.

What should be in an on-call handoff?

Six things: open incidents with current status, watch items that fired and self-resolved, known noise with an expiry date, changes landing in the incoming shift, anything currently suppressed or overridden and when it ends, and anything else you would not want to inherit without being told. Write it in a public channel rather than a direct message, and keep it to about two minutes.

How do you handle vacations and sick days in an on-call rotation?

With overrides, recorded in the same system that routes the pages. A swap agreed verbally or in a direct message is not a swap, because the alert will still ring the person who is away. Book known absences at least two weeks ahead, and have a written rule for same-day sickness, usually that the secondary becomes primary and the next tier moves up behind them.

Should on-call be paid?

Whether it must be paid depends on your jurisdiction and on how restricted the person is while on call: how quickly they have to respond, and how much of their own time is genuinely theirs. Whatever the legal position, write the policy down before the first shift rather than after six months. Pay for availability rather than only for incidents, and if you use time off in lieu, make sure it is actually taken.

Is follow-the-sun worth it for a small team?

Usually not. Follow-the-sun eliminates night pages, but only if you have genuinely staffed engineering teams in three regions who own overlapping services. With one main team and a thin presence elsewhere, you get the coordination cost of frequent cross-timezone handoffs while the thin regions escalate everything back to the main team anyway. Below that threshold, a weekly rotation with a real secondary is the better trade.

Can you run an on-call rotation on a spreadsheet?

For a very small team with few alerts, yes. It stops working when the schedule has to route the page, because a separate rota and alert-routing system will drift and the drift surfaces during an incident. The other triggers are needing automatic escalation when nobody answers, editing overrides most weeks, and being asked for records of who was on call when.

How do you know if your on-call rotation is working?

Track five numbers monthly: pages per shift, out-of-hours pages per shift, the percentage of pages that escalate to the secondary, time to acknowledge, and the spread between the busiest and quietest person over a quarter. A rising escalation rate is usually a notification-delivery problem rather than a discipline problem. Do not judge a rotation on time to resolve alone, since that moves for many reasons unrelated to the schedule.