The Real Cost of a Bad On-Call Rotation
On-call burnout doesn't announce itself. It shows up as slow incident response, engineers quietly updating their LinkedIn profiles, and a growing cultural belief that being paged is punishment. None of that is inevitable.
A well-designed rotation respects that humans need sleep, context, and predictability. Here's how to build one.
Right-Size Your Rotation
The minimum viable on-call rotation is usually four to six engineers. Below four, individuals are on-call too frequently to recover. Above a certain size, people lose the context needed to respond effectively.
If your team is smaller than four engineers with the right knowledge, that's a staffing and documentation problem to solve before you formalize a rotation — not after.
Shift length matters more than people think
Weekly rotations are the industry default, but they create a predictable misery window. Consider:
- One-week shifts work if handoff overhead is low and the rotation has enough people.
- Follow-the-sun (shifts handed off across time zones) reduces overnight pages but requires real cross-region coverage, not just a name on a schedule.
- Split shifts (weekday daytime vs. overnight/weekend) let you compensate engineers differently for antisocial hours, which is only fair.
Whatever you choose, write it down and make the schedule visible at least four weeks in advance so people can plan their lives.
Define What "On-Call" Actually Means
Vague expectations create anxiety. Before someone joins the rotation, they should know:
- Expected response time by severity (e.g., P1: 5 minutes, P2: 30 minutes, P3: next business day)
- What counts as a page-worthy alert vs. noise that should be suppressed
- Escalation path — who do they call if they're stuck, and is that person actually reachable?
- What tools and access they'll have on a Saturday at 2 a.m.
If your runbooks aren't findable from a phone in under two minutes, they're not useful during an incident.
Reduce Alert Noise Ruthlessly
Alert fatigue is a more immediate threat than most teams acknowledge. An engineer who gets woken up three times a week for alerts that resolve themselves will stop taking pages seriously — exactly when you need them to.
Audit your alerts regularly:
- Tag every alert as actionable or informational. Informational alerts should never page.
- Track alert-to-action rate. If an alert fires ten times and only twice did an engineer do anything, tune or remove it.
- Raise thresholds before lowering them. It's easier to tighten a loose threshold than to re-earn trust after weeks of noise.
- Review suppressed alerts monthly. Suppression can mask real degradation.
Using a monitoring tool with good alert grouping and routing (rather than raw webhook floods) makes this dramatically easier. If you're running multi-region checks with something like Pingy, you can confirm whether an alert is a genuine outage or a single-region blip before it wakes someone up — that kind of confirmation layer is worth having.
Build In Recovery Time
An engineer who handles a major incident at 3 a.m. should not be expected to be fully productive at 9 a.m. This isn't a policy suggestion — it's basic cognitive reality.
Practical ways to handle this:
- Flex time: Engineers coming off a rough night take time back, no questions asked.
- Incident buffer days: After a Sev-1, the on-call engineer gets the next day to write the postmortem and rest, not to take meetings.
- Cap consecutive on-call shifts. Nobody should cover for an absent colleague by doubling up more than once in a row without explicit conversation.
Run Useful Postmortems
Postmortems shouldn't be blame sessions or box-ticking exercises. They should answer: what made this incident harder than it needed to be?
That framing surfaces on-call problems directly. If the answer is "the runbook was wrong" or "I couldn't reach the escalation contact" or "the alert fired 40 minutes after the actual outage started," those are fixable.
Rotate postmortem facilitation so no single person becomes the institutional memory — or the bottleneck.
Key Takeaways
- A rotation smaller than four engineers is a retention risk, not just a scheduling inconvenience.
- Set explicit expectations (response times, escalation paths, tooling access) before someone goes on-call for the first time.
- Audit alert noise regularly; an alert that doesn't require action shouldn't wake anyone up.
- Recovery time after difficult incidents is operational, not optional.
- Postmortems should identify what made the on-call experience harder, not just what caused the outage.