Sustainable On-Call Rotations: The Six-Person Pattern
Most on-call burnout is structural, not cultural. Six people is the minimum that gives a humane rotation; below that, every absence breaks the math. Here is the design.
Why six is the floor
With one week per rotation and one primary on-call engineer at a time, six people gives each engineer one week in six, about 17% of their time. That is the upper bound of "sustainable" by every burnout study published in the last decade. Below six, the math breaks: someone going on vacation pushes the rest into one-week-in-four or worse, and the rotation visibly grinds the team down within months.
Six is also the minimum that makes a secondary rotation possible without doubling the burden, a separate set of three people, each on secondary one week in three, kept distinct from the primary so vacations do not collapse both at once.
The quiet-rotation pattern
The deep-work loss from on-call is not the actual pages, it is the constant background expectation that one might come. Engineers on-call rarely take on long-context work; they default to bug fixes, doc updates, code review. A week of on-call is, in practice, a week of zero ticket-shipping.
The quiet-rotation pattern formalises this. The on-call engineer is explicitly assigned no sprint commitments. Their job for the week is incident response, on-call improvement work (runbooks, dashboards, alert tuning), and being a fast PR reviewer. The team plans capacity assuming they ship nothing else.
This sounds like 20% capacity loss and feels like a nightmare to engineering managers. In practice it codifies what was already happening invisibly. The pre-formalisation team also lost the engineer's output; they just pretended otherwise and felt mysteriously slow.
Follow-the-sun, the right way
Follow-the-sun rotations, handing on-call between three regional teams every 8 hours, are sold as the burnout fix. They are the burnout fix when implemented well; they are the burnout multiplier when implemented badly.
The good version. Three colocated teams of four to six people, each owning their region's hours and handing off cleanly via shared incident channels and a structured handoff doc. Each engineer is on-call in their daytime hours; nights and weekends belong to the next region.
The bad version. One distributed team scattered across regions, each engineer "covers their timezone." The result: every engineer is technically on-call all the time, with the social pressure to respond outside their window. This is worse than centralised follow-the-people.
The honest test. If the rotation requires a single engineer to be reachable across more than 12 contiguous hours, it is not really follow-the-sun. Fix the team structure before fixing the rotation.
A healthy alert budget
A useful number to track: pages per on-call shift. Below 2 pages per week is healthy. 3-5 is acceptable. 6+ is a flashing red light, the alerts are noisy, the system is broken, or both. Track this metric and discuss it in retros.
Each page should have a runbook link, a clear owning team, and an honest "what action does the on-call engineer take" answer. If a page exists where the answer is "page someone else," that page is misrouted; fix the routing instead of teaching humans to be a routing layer.
Quarterly alert review. The on-call team, not management, decides which alerts to retire, which thresholds to adjust, which to consolidate. Engineers who get woken up have the strongest interest in fewer false alarms; give them the authority.
Antipatterns
One-person rotation. Inhumane. Always. Even if it is "just for a sprint." Find one more person; if you cannot, the system is not ready for production hours.
No on-call compensation. Time matters more than money for most engineers, but recognition matters too. Either time off in lieu, an on-call stipend, or both.
Treating on-call as junior work. Senior engineers absent from rotation send a strong signal. Either the rotation is bad and they should fix it, or it is fine and they should be in it.
What to do this week
Three moves. (1) Count your rotation members; if below six, write the proposal to expand. (2) Measure pages per shift over the last quarter, if any week exceeded six, schedule an alert review. (3) Add explicit "on-call quiet week" capacity to your sprint planning so the loss is visible and discussed.