Guideby Uptime Room· September 24, 2026· 7 min read

On Call Rotation: The Arithmetic Before the Calendar

An on call rotation starts with headcount arithmetic, not a calendar. Here is the pool size, the shift boundary and the handoff that make one hold.

An on call rotation is a repeating schedule that names one responder at a time for production alerts. Most teams draw the calendar first and find the arithmetic afterwards. Do it the other way round. Work out how many people the coverage you want actually needs, pick a shift length, then decide what the pager is allowed to send them.

How many people does an on call rotation need?

Coverage is arithmetic before it is culture. Round-the-clock cover is 168 hours a week. Divide that by the hours you are willing to hang on one person, and the minimum headcount falls out. Every other question in the schedule is a preference sitting on top of that number.

Datadog publishes its own target. In a post dated March 2025 the team says it aims for six to eight engineers per rotation so that nobody serves more than once a month. Google's SRE book sets the other boundary, capping on call load at two incidents per 12-hour shift, because a third leaves no room to handle any of them properly.

Pool size	Primary duty comes round	Verdict
2	Every other week	One holiday and there is no cover at all
3	Every third week	Only honest if the scope is business hours
4 to 5	Roughly monthly	The realistic floor for round-the-clock duty
6 to 8	Every six to eight weeks	Datadog's stated target as of March 2025

Below four people you do not have a rotation. You have two names and a shared calendar, and the second name is usually whoever answers their phone. Hire, widen the scope to business hours, or accept that nights are best effort and say so out loud.

Weekly, daily, or follow the sun

Three shapes cover almost every team. Weekly shifts hand one person a full seven days, which keeps context intact and lets a slow-burning problem stay with the person who started it. Daily or twelve-hour shifts spread the damage when volume is high. Follow-the-sun gives everyone daylight hours and needs offices in at least three time zones.

We prefer a weekly shift with a Wednesday boundary for any team under ten people. A Monday handoff collides with planning, and a Friday handoff parks an unfamiliar system with someone for the whole weekend. Wednesday gives the incoming responder two ordinary working days to read up before the first quiet night.

Follow-the-sun sounds like the humane option and usually is not, unless the three regions are genuinely staffed. Two regions leaves an eight-hour hole that somebody covers from bed anyway, and now the handoff happens twice a day across a language and a time zone.

What a handoff has to carry

A shift boundary is where an on call rotation drops context, and it is cheap to fix. Write the handoff down rather than saying it in a call. Four things belong in it, and a fifth is optional.

Anything still open, with the current theory and what has been ruled out.
Anything that fired and was dismissed, plus why it was safe to dismiss.
Changes shipping during the incoming shift, with who is driving them.
Every monitor that is paused or inside a maintenance window, and when it comes back.

That last one causes more trouble than the rest combined. A monitor paused at 2am on Tuesday by someone who is now off for a week is a check nobody is running and nobody remembers.

The incident history is available over the REST API, so the outgoing responder can paste the week rather than reconstruct it from memory. Authenticate with a Bearer key and read the incident list.

curl -s "https://uptimeroom.com/api/v1/incidents" \
  -H "Authorization: Bearer urm_live_..."

The full endpoint list lives in the API reference. Teams that generate the handoff note this way tend to keep writing them, because the boring half is already filled in.

Configure the checks before you publish the calendar

An on call rotation inherits whatever the monitoring layer decides to send it. Publishing the on call schedule first means the first responder discovers your threshold choices at 3am. Set the monitors up so a state change means something, then name the people.

Two settings do most of the work. Requiring more than one probe region to agree removes single-path network noise, and requiring more than one failed cycle removes the one-off timeout. Both are per-monitor fields.

{
  "name": "checkout",
  "type": "http",
  "target": "https://example.com/api/checkout/health",
  "intervalSec": 60,
  "regions": ["london", "singapore"],
  "alertAfterCycles": 2
}

In our testing on a two-region setup, that pair took a small commerce API from four pages a week down to one. The one real failure still alerted inside two minutes. There are six probe regions to choose from as of September 2026, and each one publishes its egress addresses if your firewall needs them. The list sits on the probe IPs page.

The volume question has a procedure of its own, and it deserves an afternoon rather than a paragraph. Counting pages per responder and deciding what is allowed to wake someone is covered in cutting alert noise.

Escalation, and where the schedule actually lives

An external checking service decides that a state changed and which channel receives the alert. It holds no model of who is awake, no rota and no escalation ladder. Those belong in a paging tool, and the alert routes into that tool rather than trying to replace it. There are 16 channel types to route through, including a direct PagerDuty integration.

Whatever holds the ladder, three rules make it work. Give the primary a fixed acknowledgement window, five or ten minutes, after which it moves. Name a real secondary, not a group alias that pages nobody. Put a manager at the top of the ladder, because the third unanswered page is a staffing problem rather than a technical one.

Test the ladder on a weekday afternoon once a quarter. Fire a real alert, let the primary ignore it on purpose, and watch where it goes. Roughly half the escalation policies we have looked at had a broken step nobody had exercised since the day it was written.

What the rotation is for

The point of a rota is a fast, correct first response, not a warm body. That means the person holding the pager needs a runbook, permission to make the call, and a declaration threshold they do not have to argue about at 3am. The mechanics of declaring and running the incident once it starts are in incident response.

It also means the on call schedule is a budget line. Time on call is time, whether or not anything fires, and teams that pay for it get better handoffs and fewer quiet resignations. Shift-work industries have priced this for decades. Engineering mostly still pretends it is free.

Common mistakes

An on call rotation of one, with extra steps. The calendar shows four names, but three of them route to a channel nobody watches. Send a test page to each person during their first shift.

Rotating the pager but not the knowledge. If only one person can restart the payment service, the rota is decorative. Every shift that touches something undocumented should leave a runbook behind.

Scheduling by fairness instead of coverage. Equal shift counts feel fair and can still leave one person holding every holiday. Count hours and weekends separately, then even those out.

Starting the rota during a bad quarter. A rotation built while the system is on fire encodes the fire. Fix the top three noisiest monitors first, then start the schedule.

An on call rotation works when the arithmetic comes first. You want enough people that duty returns monthly at worst, a shift boundary that carries real context, and checks tuned so a page means a customer is affected. Get those three right and the tooling underneath matters much less than the vendors suggest. Cross-region confirmation and per-monitor failure thresholds are available on every plan, including the free one, and the current limits are on the pricing page.

FAQ

How does an on call schedule work?

A schedule maps each block of time to one named primary responder and one backup. Alerts route to the primary first. If nobody acknowledges within a fixed window, usually five or ten minutes, the alert escalates to the backup and then to a manager. Shifts hand over on a fixed boundary with a written note covering open problems and paused checks.

What does an on-call position mean?

It means you are the named responder for a defined period and are expected to answer a page within an agreed time. It is not the same as working that whole period. In engineering rotations the duty is usually a week long, carried alongside normal work, with the expectation that most shifts are quiet if the alerting is tuned properly.

How many engineers do you need for a rotation?

Four to five is the realistic floor for round-the-clock duty, which puts the shift on each person roughly monthly. Datadog aims for six to eight per rotation so nobody serves more than once a month, in a post dated March 2025. With three or fewer, restrict the scope to business hours rather than pretending nights are covered.

What is a 4-3-3-4 rotating schedule?

It is a shift-work pattern from industries with continuous cover, where a team works four days, then three, then three, then four, alternating with rest blocks. Engineering rotations rarely use it, because the duty is carried alongside normal work rather than replacing it. Weekly shifts or twelve-hour blocks are the usual equivalents.

What are the disadvantages of on-call staffing?

Sleep disruption and attrition are the visible costs. The hidden one is slower response, because a responder who has dismissed several false alerts stops reading the next one immediately. A small pool makes it worse, since duty returns before anyone has recovered. Cutting the alert volume usually helps more than changing the schedule does.

#monitoring #guide #on-call #escalation #incident-response