Would you run on-call as week-long shifts or as daily or 12-hour shifts, and what drives that choice?

## The two shapes **Week-long shifts.** One person holds the pager for seven days, usually handing off on a fixed weekday. This is the most common shape in software teams. **Short shifts.** Either daily rotations, or a day/night split — commonly two 12-hour shifts — where the night slot is staffed separately, sometimes by people whose working hours are shifted to match. ## What weekly buys and what it costs The benefit is continuity. Incidents rarely resolve cleanly inside twelve hours: a slow memory leak, a creeping queue backlog, a partner outage with a vendor ticket open all take days. The person who saw the first symptom on Monday recognises its return on Wednesday. A weekly rotation also has exactly one handoff per week, so there is one moment where context can be dropped rather than fourteen. The cost is concentration. If the week is bad, one human absorbs all of it, and there is no recovery point inside the shift — you cannot hand the pager back on Wednesday morning because Tuesday night was broken. That is why teams that run weekly shifts need an explicit override norm: after a genuinely destroyed night, someone else takes the next day, no negotiation required. Without that lever, weekly on-call is a bet that no week is ever very bad. ## What short shifts buy and what they cost Short shifts localise damage. A bad night ends at breakfast. In a true day/night split with shifted working hours, night pages reach a person who is awake, alert and not about to work a full day afterwards — which is the only arrangement that genuinely removes the sleep-deprivation problem rather than redistributing it. The costs are real. Handoffs multiply: two a day is roughly fourteen a week, and everything that must transfer — open silences, in-flight changes, manual mitigations — has fourteen chances to be lost. Ownership of slow problems fragments, because nobody holds the thread long enough to see a pattern across days. And short shifts consume rotation depth: with six people, a daily rotation means being on call roughly every sixth day, which is a very different rhythm from nine weeks a year, and it interleaves interrupt duty with project work far more often. ## The inputs that actually decide it - **Night page volume.** A service that pages two or three times most nights cannot be run on week-long single-person shifts; nobody survives seven of those in a row. A service where nights are almost always silent runs weekly comfortably. - **Typical incident duration.** If problems routinely span days, continuity is worth more than fatigue containment. - **Rotation depth.** Short shifts need enough people that each person is not on call every few days. - **Whether night duty is properly compensated and time-shifted.** A "night shift" where the same person still works the next day is a weekly rotation with extra handoffs and none of the benefit. ## The honest caveat When a team is choosing shift shapes primarily to survive its night page volume, the shift shape is not the real answer. Two or three pages a night is a signal about what has been made pageable and about the reliability of the service; redesigning the rotation redistributes that pain without reducing it. A strong answer names both moves: change the cadence to make the next month survivable, and treat the page rate itself as work to be fixed. ## A common middle ground Many teams land between the two shapes: a weekly primary that covers business hours and evenings, with a separately staffed night slot or a partner region taking the small hours; or a weekly rotation with a firm same-day override rule after a broken night. Both keep one owner for continuity while removing the worst of the concentration.