How to Design an On-Call Schedule That Actually Works

At a glance

An on-call schedule answers one question at every instant: who gets the page. Rotation length, handoff time, fairness and tooling all exist to keep that answer unambiguous and survivable.

Schedules fail in three recognisable ways. Nobody is on — a coverage gap. Several people assume someone else is on — diffused ownership. Or one person is on far too often — an attrition problem with a delayed fuse. A good design closes all three, and it is mostly decided before anyone drags a name onto a calendar.

Start with the coverage requirement

Write four things down, in plain sentences, before opening a scheduling tool.

• Scope. Which services, and which alerts, route to this rotation.
• Hours. The wall-clock windows that need a human, stated in a named time zone.
• Response expectation. How fast the person is expected to acknowledge, and what they need to hand (laptop, VPN, credentials).
• Fallback. What happens when that person does not answer.

If you cannot fill in all four, the gap is in the design, not in the tool. A requirement like "24/7 for the payments API, acknowledge within 15 minutes, laptop reachable, escalate to secondary after 10 minutes unacknowledged" is enough to build a schedule around. "Someone should keep an eye on things" is not.

Choosing a rotation length

Rotation length trades context retention against recovery time. Longer shifts keep an investigation with one person; shorter shifts limit the blast radius of a bad week.

Two practical constraints narrow the choice quickly. First, work out the real recovery gap — shift length multiplied by the number of people in the rotation minus one, so five people on weekly shifts get four weeks off between them — and compare that gap with how long people on this team need after a bad shift. If it is shorter, the fix is more people or fewer pages, not a different pattern. Second, count the handoffs the pattern creates each week and multiply by the time a handoff actually takes here. If nobody will spend that time, the handoffs get skipped and the pattern is the wrong one.

Handoff timing

Set the handoff at a time when both the outgoing and incoming engineer are awake and working. That usually means a fixed weekday morning slot in the team's main working time zone, not midnight and not the Friday evening boundary.

Avoid handing over immediately before a deploy window, a scheduled migration or a known traffic peak. The person receiving the shift should have a quiet hour to read what they are inheriting.

Primary and secondary

The secondary is not a spare primary. It exists because people miss pages for ordinary reasons: a phone on silent, a tunnel, a dead battery, a shift that started with a migraine.

Define the two triggers explicitly. The first is automatic — the page is not acknowledged within a set time and escalates. The second is manual — the primary asks for help, which should carry no social cost at all.

Two rules keep this honest. The secondary must be able to act, not only advise: access, credentials and runbook knowledge included. And one person should not be primary on one rotation and secondary on another during the same week, unless the team has genuinely agreed that this is one workload rather than two.

Time zones, holidays and leave

Store and reason about the schedule in UTC; display it to people in their local time. Then check three things that quietly create gaps.

• Daylight saving. Regions change on different dates. A shift boundary defined in local time can overlap or leave an hour uncovered twice a year.
• Public holidays. They differ by country and sometimes by region within a country. A rotation that silently assumes one national calendar will lose a day.
• Leave. Approved time off should update the schedule when it is approved, not the week it starts.

Every swap must change the schedule itself. An agreement in chat is not a schedule change: the alert still routes to the original person, and the person actually available never sees it. Use the tool's override mechanism so the change is visible to anyone checking who is on call.

Fairness: measure what actually costs

Total hours assigned is a poor fairness measure, because two people can hold identical hours and have completely different experiences of them.

Count the things that hurt, per person, per quarter:

• Nights woken (pages received between the team's agreed sleeping hours)
• Weekend days held
• Public holidays held
• Pages received per shift, and how many required action

Publish the counts to the team. Visible numbers are what turn "I feel like I always get the bad weeks" into a schedule change, and they are also the input to any compensation or time-off-in-lieu policy.

Small teams: the honest version

A two-person rotation is not a fair rotation. It is alternating permanent responsibility, and no rotation pattern, shift length or clever calendar trick changes that. Each person is either on call or the only fallback, permanently.

If you have two people, choose from the real options rather than the imaginary one:

1. Reduce what pages. Cut the alert set to conditions that genuinely need a human at night. It costs no headcount, and it is the only option on this list the team can act on without anyone else's agreement.
2. Narrow the covered hours. Commit to a slower documented overnight response instead of pretending to a 24/7 target you cannot staff.
3. Borrow a third and fourth person. An adjacent team, a manager who takes the fallback slot, or a shared rotation across two small teams.
4. Pay for it explicitly. Standby compensation does not make the load fair, but it stops it being invisible.

State which option you have chosen, in writing, so that the people carrying it and the people depending on it hold the same expectation.

Test the schedule before production depends on it

Do these five checks against the schedule you have just built.

• Walk the next 90 days and confirm exactly one primary at every hour.
• Cross the daylight-saving boundaries in every region involved.
• Overlay each region's public holiday calendar.
• Make an override, then confirm a test page follows it.
• Send a real test page to the primary and to the secondary path, on their actual devices.

Worked examples

The following are invented examples used to show the shape of a working schedule. They do not describe any real team.

Team of two, business-hours SaaS. They stop pretending to run 24/7. Alerts are split: a small set of customer-facing failures pages at any hour, everything else waits for the morning queue. The two engineers alternate weeks; the engineering manager is the named fallback and is called by phone rather than paged. Standby is compensated. The written policy says overnight acknowledgement is best-effort within 30 minutes.

Team of five, one time zone. Weekly primary rotation, handoff Tuesday at 10:00 local, with a shared handoff note. Secondary rotates on the same weekly cycle, offset so that the incoming primary was the previous secondary. Nights woken and weekend days are reviewed at the monthly team meeting.

Team of twelve, two regions. Six engineers per region, each region running its own weekly primary and secondary. Handoff at the regional boundary is a fifteen-minute call with a written summary. Neither region covers the other's nights; if one region drops below four available engineers, the rotation collapses back to a single follow-the-sun-free weekly schedule until it recovers.

What to do next

Work through this today:

• Write the coverage requirement in four sentences: scope, hours, response expectation, fallback.
• Choose a rotation length and name the trade-off you accepted.
• Fix a handoff time when both parties are awake and working.
• Confirm the secondary can act, not only advise.
• Walk the next 90 days for gaps, DST changes and holidays.
• Send one real test page and one override test.
• If the team is two people, pick one of the four options above and write it down.