On-Call Schedule Best Practices for Small Teams
A rotation designed for a twenty-person SRE organization will burn out a four-person team fast, and a rotation designed for a small team will feel oddly under-structured if applied wholesale to a large one. On-call scheduling isn't a solved problem with one right answer — it's a set of tradeoffs that land differently depending on team size, and getting the shape wrong is one of the more common, avoidable causes of on-call burnout.
Shift length
A week-long rotation is the most common default, and it works reasonably well for teams of five or more: each person is fully off-call for several weeks between shifts, giving real recovery time. For teams of two or three, a week-long rotation means each person is on-call roughly half the time or more, which is a genuinely heavy load regardless of how quiet the alerts actually are — just being reachable and unable to fully switch off is its own cost.
For very small teams, shorter rotations — two or three days — spread that constraint more evenly, at the cost of more frequent handoffs. There's no universally correct shift length; the right one is whatever keeps each person's on-call frequency at a level they can sustain indefinitely, not just survive once.
Handoff timing
Handoffs should happen at a predictable, low-traffic time — early morning on a weekday tends to work well, avoiding both the highest-traffic hours and the temptation to hand off right before a weekend when nobody's fully paying attention. A handoff that happens mid-incident, purely because the clock ran out, is its own hazard — build in a brief overlap window rather than a hard cutoff, so an in-progress incident doesn't get orphaned between two people mid-response.
Primary and secondary coverage
A rotation with only a primary on-call person and no secondary is a rotation with a single point of failure. If the primary's phone dies, or they're already on another call, or they simply don't respond in time, there needs to be a defined secondary who picks it up — not a scramble to figure out who's actually reachable in the moment. This is the scheduling equivalent of an escalation policy: the schedule itself should already answer "who's next" before an incident ever makes that question urgent.
Overrides matter as much as the base schedule
Rotations are planned in advance. Life isn't. Someone will get sick, have a family emergency, or simply need a specific day off that lands during their scheduled week. A rotation without an easy override mechanism creates real pressure to grit through an on-call shift a person shouldn't be covering — which is worse for everyone, including whoever eventually gets paged and reaches someone who's not actually able to respond well.
A "cover now" mechanism — letting any team member claim an in-progress shift or pick up coverage on short notice — solves this without requiring a manager to manually reshuffle the schedule every time. PingParrot's on-call scheduling supports exactly this: recurring rotations with a straightforward override any team member can claim, so a schedule change doesn't require rebuilding the whole rotation around one exception.
Review the schedule against real fatigue signals
The best test of whether a rotation is structured correctly isn't a policy debate — it's the team's actual paging data. Rising acknowledgment times, an uneven distribution of who's covering weekends, a pattern of swap requests concentrated around one person's slots — all of these are signals that the schedule's shape, not just individual willpower, needs adjusting. A rotation that's never been reviewed against this kind of data is a rotation running on the assumption that the original design was correct and stays correct as the team changes, which is rarely true for long.