How We Handle On-Call Without Burning Out the Team

Every team that supports live systems eventually needs an on-call rotation -something breaks outside business hours, and someone needs to be reachable. The part that's easy to get wrong isn't having on-call. It's running it in a way that doesn't slowly grind down the people on it. We've adjusted our approach more than once after noticing exactly that starting to happen.

Why We Rotate on a Fixed, Predictable Schedule

Unpredictable on-call assignments -asking whoever's available in the moment - feels flexible but actually creates more stress, because nobody can plan around it. We run a fixed rotation, published weeks in advance, so each person knows exactly when they're on and can plan their life around the weeks they're not. Predictability, even when the rotation itself is demanding, reduces the background anxiety of not knowing when you might get pulled in.

Why Not Everything Warrants a 2 A.M. Page

The biggest driver of on-call burnout isn't the existence of alerts - it's alerts that don't actually need immediate action. We audit our alerting thresholds specifically to separate "wake someone up now" from "flag it, deal with it in the morning." A slow degradation that won't meaningfully affect users for hours doesn't need to interrupt someone's sleep. Getting this distinction right took real iteration - we've had alerting configurations that paged too aggressively, and we scaled them back once we tracked how many pages turned out not to need immediate action.

We Track Page Volume Per Person, Not Just System Uptime

Uptime metrics tell you whether the system is healthy. They don't tell you whether the on-call rotation is sustainable for the people running it. We separately track how many pages each person receives during their rotation and treat a consistently high number as a signal to fix, not something to just tolerate as the cost of reliability. If one part of the system generates a disproportionate share of pages, that's a signal the underlying issue needs engineering attention, not just faster on-call response.

Compensation and Time Off Aren't an Afterthought

Being on-call is real work, even in weeks where nothing goes wrong - it constrains what you can do with your evenings and requires being reachable. We compensate on-call time distinctly from regular hours, and a rotation that involves an actual overnight incident gets recovery time built in afterward, not an expectation of showing up at full capacity the next morning. Treating on-call as free extra availability is one of the fastest ways to make a rotation something people dread rather than just accept as part of the job.

Escalation Paths Exist So One Person Isn't Ever Fully Alone

No one on our on-call rotation is expected to resolve every possible incident single-handedly. A clear escalation path - who gets pulled in for what category of issue, and how quickly - means the person on-call isn't stuck holding an incident they don't have the context to fix alone at 3 a.m. This matters as much for morale as for resolution speed: knowing backup exists changes how stressful the rotation feels, even in weeks where it's never used.

What We Review After Every Significant Incident

After anything that involved a real overnight page, we don't just do a technical postmortem - we ask whether the alert should have fired the way it did, whether the person on-call had what they needed to resolve it, and whether the rotation itself held up reasonably. This is where most of our actual process improvements have come from: not abstract planning sessions, but specific incidents that revealed a gap in either the system or the rotation structure supporting it.