On-Call Overrides: Handling Vacation, Sick Days, and Holiday Coverage Without a Scheduling Mess
On-call rotations usually don't break because of bad rotation design — they break because vacations, sick days, and holidays get handled as manual schedule edits instead of temporary overrides. A proper override sits on top of the base rotation for a specific date range and expires automatically, so the underlying schedule never has to be hand-edited or reconstructed later.
Should you just edit the schedule directly when someone needs coverage?
No — not if the rotation needs to keep working after that one swap. The tempting fix when someone needs coverage is to just edit the schedule directly: swap two names, move the rotation order around, and move on. That works exactly once. The problem shows up the next time the rotation needs to be reasoned about.
The base order no longer matches what anyone remembers. "Whose turn is it normally" stops having a clear answer. Untangling a rotation that's been hand-edited a dozen times over six months becomes its own project. The rotation is supposed to be the thing everyone can trust without checking — every manual edit erodes that a little more.
Overrides as a temporary layer
The better model treats an override as something that sits on top of the base rotation for a specific date range, then disappears automatically once that range ends. This is the same pattern the iCalendar standard, RFC 5545, uses for calendar events: a recurring event defines the base pattern, and a specific override for one occurrence — an EXDATE plus a replacement instance — doesn't alter the recurrence rule itself. The underlying rotation resumes exactly where it would have been if the override had never happened. Nobody has to remember to revert anything. The base schedule stays a clean, trustworthy source of truth that reflects the actual long-term rotation, not a patchwork of one-off edits nobody fully remembers making.
The override-as-temporary-layer model matters just as much for the short-notice case as it does for a planned vacation. Someone waking up sick with no warning needs coverage assigned in minutes, not after a round of "does anyone have five minutes to fix the schedule." An override that's quick to create and automatically bounded to that one day handles both cases with the same mechanism. The only real difference between a planned two-week vacation override and an unplanned one-day sick override is how far in advance it gets set up.
The same logic applies to a mid-rotation shift swap that has nothing to do with being out sick. Two engineers trading Tuesday for Thursday because one of them has a conflict is a two-minute override, not a rotation redesign.
None of it needs to touch the base rotation at all.
The habit worth building is treating every deviation from the base schedule — sick day, vacation, a traded shift, a holiday — as the same kind of temporary override, rather than deciding case by case whether it's "big enough" to warrant doing it properly.
The holiday-specific version of this problem
Holidays make the same problem worse in a specific way. Instead of one person needing coverage, several people want the same week off at once, and the gap that needs filling isn't always obvious until it's too late to fix cleanly. Christmas through New Year's is the sharpest version of this. It's common for a majority of a small team to want at least part of that stretch off, which leaves very little slack to actually cover it. The failure mode isn't usually "nobody volunteered" — it's that nobody had clear visibility into who had volunteered, or who was already covered. That gap usually surfaces the hard way: an alert goes out on the holiday itself and reaches the wrong person, or nobody at all.
The fix is mostly about visibility ahead of time, not clever scheduling logic. A clear view of who's covering which day, set two to three weeks before the holiday period starts, catches gaps during planning. That's the alternative to finding them the hard way, through an actual page that goes nowhere. Waiting until the week of the holiday to sort it out is usually waiting until it's too late to find a volunteer who isn't already covering something else.
What to actually look for in a scheduling tool
A few specific things separate a scheduling tool that handles this well from one that turns every vacation into a small project:
- Temporary override windows with a clear start and end date, rather than a permanent edit to the rotation order.
- A clear "who's on call right now" view that reflects overrides, not just the theoretical base rotation — so anyone checking gets the real answer, not the normal-week answer.
- Self-service swaps that don't require an admin to manually intervene every time two people want to trade a shift.
The self-service swaps point matters more than it sounds like it should. A tool that requires an admin to manually rebuild the schedule for every swap turns a two-minute trade between teammates into a multi-day back-and-forth. The admin becomes a bottleneck for something that shouldn't need one — which is also why Google's SRE book treats a low-friction handoff mechanism as part of what makes an on-call rotation sustainable, not an optional nicety.
Where this fits in PingParrot
PingParrot's on-call schedules support overrides as exactly this kind of temporary layer. Set a date range, assign coverage, and the base rotation resumes automatically once it ends. The current on-call person always reflects whatever override is active, so the "who's on call right now" view is never showing a stale, pre-holiday answer. Nobody has to remember to revert a swap after the holiday. And nobody has to hand-edit a rotation that's supposed to keep working correctly for the other eleven months of the year too.