# On-Call Is a Design Constraint

> The pager is a feedback loop, and where you point it decides what gets built.

Source: https://christwentyfour.com/blog/on-call-as-a-design-constraint

On-call is usually treated as a cost to schedule and split fairly. It is also a feedback loop, and where it points decides what gets built.

## Whoever ships should carry the pager

When the team that writes a service gets woken by it, the design changes. Retries get bounded. Errors say what to do. Timeouts get set on purpose. When those are different teams, the people who could prevent problems most cheaply never feel them.

## A quiet pager is doing its job

Most busy shifts are unfinished work: something the system should have handled, something that should have been caught earlier, or a real new failure. Only the last one needs a person at night. Track the split. If most pages are the first two kinds, adding people to the rota will not help.

## Make the shift survivable

- One primary, one backup, and a documented way to wake someone with more context.
- Shifts long enough for continuity and short enough to recover from. A week is common.
- An explicit rule that a bad night means a lighter next day.
- A handover that covers what fired, what is still open, and what to watch.

## Give the rotation time to fix things

The usual mistake is putting someone on call while expecting full delivery that week. Pages get acknowledged, and nothing improves. The person carrying the pager needs time and standing to delete a bad alert or write the missing runbook.