Blog
Rotation models for teams of 2 to 8, a handover checklist, holiday overrides, do-not-disturb hours and a simple rule for which alerts wake someone up at night.
A workable on-call rotation for small teams is a weekly primary shift with a named secondary, handed over at a fixed time on a weekday, with overrides for holidays and sick days. The schedule only stays sustainable if a strict rule decides what may page at night: customer-facing, ongoing and actionable problems page, everything else waits for a channel someone reads in the morning. The rest of this guide covers which model fits 2 to 8 people, how to run handovers and overrides, and how to sort alerts into night and morning.
In a large organization, each engineer is on call a few weeks per year. In a team of three, you are on call every third week. In a team of two, every other week. That frequency is the defining constraint, and it changes what matters.
With a small team, the schedule itself is rarely the problem. The problem is alert volume. If a rotation of four people gets woken up twice a week by alerts that turn out to be noise, the team burns out regardless of how cleverly the rotation is designed. So treat the rotation and the paging rules as one system: the fewer people you have, the stricter the rules for night pages must be.
Two people can alternate weekly, but only if night pages are rare. If both live in the same time zone, keep after-hours paging limited to full outages and data-loss risks. If you are in time zones roughly eight hours or more apart, a follow-the-sun split works better: each person covers their own daytime and the late evening of the other, so nobody is woken up for most incidents.
Also agree on what happens when one of the two is on holiday. With two people, a holiday means the other is on call for the whole period, so reduce the scope further during that time, for example by accepting that warnings wait until the next business day.
This is the most common setup. One person is primary for a week, and the previous week's primary acts as secondary. The secondary already knows what happened recently and only gets paged when the primary does not acknowledge in time.
Week Primary Secondary W1 Ana Dana W2 Ben Ana W3 Chris Ben W4 Dana Chris
Everyone is primary one week in four and secondary one week in four, which leaves two quiet weeks per cycle.
With more people, a full week of primary duty becomes unnecessary. Two options work well:
At eight people, consider whether everyone should be in the rotation at all. Engineers who never touch production may add more escalation delay than coverage. Include people who can actually act on the services that page.
A handover should be short and written. Post it in the team channel so anyone can read it later. A template keeps it consistent:
On-call handover - week 23 Outgoing: Ana Incoming: Ben Open incidents: none Pages this week: 3 (2 actionable, 1 noise, ticket created) Alerts to watch: DB disk usage on replica, growing slowly Risky changes ahead: schema migration Thursday 14:00 Silenced monitors: staging API, until Friday Maintenance windows: payment provider, Saturday 02:00-03:00 Upcoming overrides: Chris covers Ben on Sunday
The most valuable line is usually "silenced monitors". A monitor muted during an incident and never unmuted is a common way to miss the next outage.
An override temporarily replaces one person with another for a defined time window without changing the underlying rotation. Use overrides instead of editing the schedule, otherwise the rotation drifts and someone ends up on call twice in a row.
Review the next four weeks of the schedule once a week, ideally during handover. Gaps are easy to fix two weeks in advance and painful to fix at 23:00.
The question for every alert is simple. An alert may wake someone up only if customers are affected right now, the problem will not resolve itself or will get worse by morning, and the person paged can actually do something about it. If any of the three is missing, it goes to the morning queue.
Applied to typical monitors, the split looks like this:
# Example severity rules critical: # pages 24/7 - website or API down, confirmed from 2+ regions on consecutive checks - login or checkout check failing - primary database unreachable - disk above 90% and still growing - SSL certificate expires within 24 hours route: on-call primary via push and SMS escalate: secondary after 15 minutes without acknowledgement warning: # business hours only - failure from a single region - response time above threshold - SSL certificate expires within 14 days - non-critical cron job missed one run - disk above 80% route: team channel, reviewed at 09:00
Two details make this work. First, critical alerts need to be confirmed before they page. A single failed check from one location is not an outage; the techniques in reducing false positive alerts with multi-region checks and retries are the precondition for a calm night rotation.
Second, decide case by case for scheduled jobs. A missed nightly report can wait. A backup job that has silently stopped for days is a different story, but even then the fix rarely has to happen at 03:00. Use heartbeat monitoring for cron jobs so a missed run surfaces in the morning queue instead of weeks later.
Do-not-disturb hours suppress notifications during defined times, typically the night and weekends. Used correctly, they protect sleep. Used carelessly, they hide outages.
The rule: do-not-disturb applies to warnings, never to critical alerts for the person on call. In practice that means:
On the phone side, check that the paging app is allowed to bypass the operating system's own focus or silent mode. This is the most common reason a correctly routed alert still goes unnoticed.
A rotation is healthy if night pages are rare and every one of them was worth it. A few habits keep it that way:
If you use m0nitor for monitoring, on-call schedules cover the pieces described above: team rotations, temporary overrides for holidays and swaps, and do-not-disturb hours, with alerts routed to whoever is currently on call. Alert workflows follow an if-this-then-that pattern on monitor events, so you can notify a channel, open an incident or call a webhook depending on what happened. Supported alert channels include email, Slack, Discord, Microsoft Teams, Mattermost, Telegram, Pushover, SMS, PagerDuty and ilert, which lets you send critical alerts to SMS or push and warnings to a team chat. The same principles apply with any other tool that supports rotations, overrides and severity-based routing.
Two people can run a rotation if night pages are rare and limited to full outages. Three to four people allow a weekly primary and secondary with quiet weeks in between, which is the most comfortable setup for most small teams. Beyond that, split weekday and weekend or business-hours and after-hours shifts.
One week is the most common length for small teams because it is easy to remember and limits the number of handovers. Hand over mid-week at a fixed time. Shorter shifts, such as weekday and weekend splits, make sense once you have five or more people.
The alert should escalate automatically to a secondary after a fixed time, for example 10 to 15 minutes. Without escalation, a single dead phone battery or muted app means nobody responds to a real outage.
No. Only alerts that affect customers now, will not resolve themselves and can be acted on should page, especially at night. Warnings such as slow responses, single-region failures or certificates expiring in two weeks belong in a channel reviewed during business hours.