A bad on-call rotation doesn't usually fail loudly — it fails as attrition. Good engineers leave teams over a rotation that pages them at 3am for things that could wait until morning, long before they'll say that's the reason in an exit interview. Designing a rotation well is mostly about a handful of structural decisions made once, carefully, rather than a pile of tooling.
Rotation length: the core tradeoff
A one-week rotation is the default for a reason — long enough that handoffs don't dominate everyone's calendar, short enough that no one engineer absorbs a bad week's worth of pages for a full month. Shorter rotations (a few days) reduce individual burden per shift but multiply handoff overhead and context-switching, since context about an ongoing issue has to transfer more often. Longer rotations (two weeks or a month) reduce handoff friction but concentrate risk: if a bad incident lands mid-rotation, that person absorbs disproportionate pain, and a month-long rotation with a genuinely noisy service is a fast way to burn someone out.
A service paging twice a month can sustain month-long rotations without anyone noticing. A service paging twice a night needs a much shorter rotation — or, more urgently, the alert volume needs to be the thing that actually gets fixed, since no rotation schedule solves a fundamentally too-noisy service.
Follow-the-sun vs. single-timezone rotations
Follow-the-sun coverage — handing the pager off between offices in different timezones so no one is ever paged at 3am local time — sounds obviously better and only actually works if you have real engineering presence in multiple timezones with enough depth to sustain a rotation in each, not just one remote engineer covering the gap alone. A single-timezone rotation with genuine off-hours paging is honest about its tradeoff: it's simpler to run and reason about, but someone will get paged at night, and that needs to be compensated and staffed for explicitly rather than treated as free.
Escalation policy design
An escalation policy defines what happens when the primary on-call doesn't acknowledge a page within some window — it escalates to secondary, then to a manager, then potentially to a wider channel. The failure mode to design against is a policy that's too patient: a 15-minute wait before escalating to secondary sounds reasonable until the primary is asleep with their phone on silent and the incident burns 15 extra minutes for nothing. A tighter first-tier timeout (5 minutes) with an automatic escalation to a secondary who's also paged is more resilient than a long chain that assumes the first person will always respond.
escalation_policy:
- level: 1
target: primary_oncall
timeout_minutes: 5
- level: 2
target: secondary_oncall
timeout_minutes: 10
- level: 3
target: team_lead
timeout_minutes: 10
- level: 4
target: incident_commander_channel
notify: always # regardless of ack, for visibilityWhy a secondary matters, not just a primary
A rotation with only a primary and no secondary means the primary's phone dying, losing signal, or being in the shower during an incident has no backstop — the page just goes unanswered until someone notices. A secondary who's paged in parallel or after a short timeout, and who is explicitly expected to be reachable (not the person who happens to pick up), closes that gap. The secondary role is also where less experienced engineers can shadow real incidents with a safety net, which is a reasonable way to grow the rotation's bench depth over time.
Alert fatigue is a rotation design problem, not just a monitoring one
Alert fatigue happens when pages regularly turn out to be non-actionable — a flapping check, a threshold set too aggressively, an alert for something that self-resolves before anyone can respond. Once that happens a few times, on-call engineers start treating every page with less urgency, which is exactly the outcome you can't afford for the page that's real. The fix is not "tell people to take alerts seriously" — it's auditing which alerts actually led to action over the last quarter and deleting or tuning the ones that didn't, on a recurring basis, not as a one-time cleanup.
If fewer than half of pages in a given rotation resulted in a real fix or a real incident, that's a signal the alerting is miscalibrated, not that the on-call engineer needs to be more diligent. Review this ratio explicitly — it's the earliest measurable sign of fatigue building before people start quietly resenting the rotation.
Compensating on-call fairly
On-call is work, even in the weeks where nothing pages — the constraint of staying reachable, sober, and near a laptop has real cost, and treating it as an unpaid extension of the regular job is one of the more reliable ways to erode goodwill on a team. Common structures are a flat stipend per rotation week regardless of pages, additional hourly pay for actual incident response time, or comp time taken afterward. Whichever model, it should be explicit and consistent, not an informal "we'll figure it out" that ends up meaning nothing happens.
Wrapping up
The rotation itself is the easy part to schedule — a spreadsheet or PagerDuty can handle that. The decisions that actually determine whether on-call is sustainable are rotation length matched to real alert volume, an escalation policy that doesn't wait too long on an unresponsive primary, a real secondary as backstop, active alert-fatigue triage, and fair, explicit compensation. Get those five right and the schedule mostly takes care of itself.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.