Badly designed on-call charges the price in retention: whoever wakes up three nights in a row updates their résumé the following week. Before you pick an alerting tool, five design decisions determine whether the rotation survives six months. The decisions below come from teams of 8 to 40 people running their own rotation, and each one closes with a number the team tracks.
One person wakes up, at most, per night
A weekly page cap and a shift with recovery time. The book Site Reliability Engineering (Beyer et al., O'Reilly, 2016) treats on-call fatigue as project risk and argues for rotation with time to recover. Pair it with an event limit: past three incidents in seven days, the next step is stabilizing the cause rather than routing more pages. Publish the number on the team dashboard.
Written handover at the end of every shift
Six lines: what changed, what is unstable, who to call. Without a handover, the next shift discovers the system by trial. Building Secure and Reliable Systems (Google, O'Reilly, 2020) links operating with explicit context to fewer human errors and treats shift change as part of the work. The record stays in the on-call channel and becomes raw material for the postmortem.
Runbook before the alert
No alert joins the rotation without a documented action. Every alert points to a ten-line runbook: what to check, what is severe, who decides the rollback. An alert with no runbook trains the rotation to call a person. Start with the alerts that wake the team more than twice a week and keep the rest out of the list. Keep the runbook in the same directory as the service, because a runbook on a wiki outside the repo ages within weeks.
Who joins the rotation
Mid-level and senior together, in pairs for the first three months. The new engineer runs on-call with someone experienced until they close five shifts without escalating an error. Whoever trains people in on-call gets two fewer shifts on the weekly count, and the swap shows up in the report.
Cost measured in sleep and rework
Two metrics: interruptions per night and hours of stabilization. The DORA State of DevOps Report reads stability and burnout in the same analysis: a team that ships fast and burns out ships less the next quarter. Bring both metrics to the quarterly rotation review, along with the list of pages by root cause.
