On-Call Burnout: Early Warning Signs and How Rotation Design Prevents It

Burnout doesn't announce itself. Nobody sends a message saying "I'm starting to burn out on this rotation" until it's already serious enough to affect their work, their sleep, or their willingness to stay on the team. Google's own Site Reliability Engineering book treats a sustainable on-call rotation as core engineering practice, not an afterthought. But the warning signs are usually visible in paging data months before anyone reaches that point — if someone's actually looking.

What are the early warning signs of on-call burnout?

A handful of patterns show up consistently before someone burns out on an on-call rotation, and they're usually visible in ordinary paging data months before anyone raises it directly:

• Rising page volume with no corresponding system change. If one person's shifts are consistently noisier than everyone else's without an obvious cause, it's worth checking whether that's coincidence or whether something in their rotation slot is genuinely different.
• Slower acknowledgment times, specifically for that person. A gradual increase in time-to-acknowledge isn't always about how they feel about the job — sometimes it's simply sleep debt catching up.
• An increase in shift swap requests. One swap is normal life. A pattern of swaps away from a particular person's slots is a signal, not noise.
• A shift from proactive to reactive. Someone who used to fix root causes during their on-call week and now just clears the alert and moves on is very often telling you something, even if they haven't said it directly.
• Going quiet in retros. Someone who used to flag flaky alerts and propose fixes in the post-incident review and now just says "yeah, same as last time" has often stopped believing the feedback goes anywhere.

None of these individually proves burnout. Together, and trending in the same direction over a few rotations, they're a pattern worth a direct conversation before it becomes a resignation conversation instead.

Having the conversation before it becomes a resignation

The hardest part usually isn't spotting the pattern — it's saying something about it before there's an obvious trigger, like a missed page or a blown incident, to justify bringing it up. Waiting for a concrete incident means waiting until the person has already had a genuinely bad week, which is the wrong time to start the conversation.

A useful way to raise a possible burnout pattern starts with the data, not with a diagnosis. Instead of opening with "are you burning out," open with what's actually observable: acknowledgment times have crept up over the last three rotations, there have been more swap requests on their slots lately, what's going on. That framing leaves room for a temporary explanation — a new baby, a family issue, a bad run of pages — without forcing the person to first agree they're burning out just to explain themselves. Sometimes the fix is small: a lighter week, a schedule swap, a second look at why their shifts keep getting noisier than everyone else's. Sometimes it's evidence the rotation itself needs to change, which is a structural problem, not a personal one.

Rotation design is prevention, not just scheduling

The instinct when burnout shows up is to address it person by person — check in, offer time off, rearrange a schedule. That helps in the moment, but it treats the symptom. The more durable fix, as Google's own Site Reliability Engineering Workbook argues in its chapter on being on-call, is designing the rotation itself so it doesn't concentrate load unevenly in the first place.

A few structural choices matter more than they get credit for:

• Shift length. A week-long rotation concentrates risk into fewer people, fewer times — but also means a genuinely bad week is a genuinely bad week for that person, with no relief until it ends. Shorter, more frequent rotations spread the same total load more evenly, at the cost of more frequent handoffs.
• Fair distribution of the worst shifts. Weekend and holiday on-call has to rotate fairly across the team, tracked explicitly — not left to whoever happened to volunteer last time, which tends to quietly overload whoever's most conscientious about not leaving gaps.
• A real override mechanism. Rotations are schedules made in advance, and life doesn't respect schedules made in advance. A rotation without an easy way to hand off a shift on short notice — a "cover now" mechanism, not a manual reshuffle — pressures people to grit through on-call weeks they shouldn't have to.
• Some form of comp time or on-call pay. Treating on-call as unpaid extra work that happens to come with a laptop is a quiet way of telling people it doesn't count — teams that acknowledge the load explicitly, even with something as simple as a day off after a rough week, tend to have less quiet resentment building underneath the schedule.

Make the data visible, not just collected

Most paging tools already have the underlying data to spot these patterns — acknowledgment times, page volume per person, swap frequency — but it's only useful if someone actually looks at it regularly instead of only after an incident review. PingParrot's delivery audit log tracks who was paged, when, and how long it took them to acknowledge, which is enough raw material to spot an uneven pattern early, as long as it's part of a regular team check-in rather than something pulled up only in hindsight.

The teams that avoid burnout on their rotations aren't the ones with the least on-call load — they're the ones who treat the paging data as an early warning system and act on it before it turns into an exit interview.