On call is the arrangement that guarantees a named human will respond to a specific class of problem within a stated time, at any hour. That sentence is doing more work than it appears to. It contains a scope, a latency target and an accountable person, and a rotation that is missing any one of the three is not a rotation, it is a list of phone numbers.

The arrangement exists because some failures cannot wait for business hours and cannot be handled by automation. Everything else that gets loaded onto on call, the routine questions, the cleanup tasks, the alerts that resolve themselves, is load that the design should be removing rather than distributing.

The scope question comes first

Before anybody argues about shift lengths or compensation, the rotation needs a written answer to one question: what is this person responsible for responding to at three in the morning? The answer should be small enough to say in two sentences and specific enough that a responder can tell, from the page itself, whether it is theirs.

Scopes that work are stated in terms of user visible behaviour and ownership boundaries together. The person on the checkout rotation responds when the checkout journey is failing or slow for users, and when a dependency the checkout team owns is the cause. They do not respond when the payments provider is down, because that belongs to a different rotation with a different runbook, even though the symptom arrives at checkout first.

Scopes that fail are stated in terms of infrastructure. A rotation responsible for "the Kubernetes cluster" will be paged for every workload any team deploys onto it, which means the responder is accountable for behaviour they did not write, cannot read and have no authority to change. This is the single most common way a rotation becomes unbearable, and it is a design error rather than a staffing one.

The latency target, written down

A rotation needs a stated acknowledgement time, because the number determines everything else about how the rotation runs. Five minutes means the responder carries a device that will wake them, stays within reach of a working connection and does not drive for long stretches alone. Thirty minutes is a different life. Neither is wrong, but the number has to be chosen deliberately and stated, because an unstated expectation defaults to the most anxious interpretation anybody on the team holds.

The target should be derived from the error budget rather than from a general sense of urgency. If the budget allows forty three minutes of full outage a month, and a typical incident takes twenty minutes to mitigate once somebody is working on it, then an acknowledgement target above ten minutes consumes most of the budget in response time alone. If the budget is four hours a month, a thirty minute target is defensible and the rotation is correspondingly cheaper to staff.

What on call is not for

Three kinds of work get attached to rotations and should not be. The first is routine operational requests: access grants, data corrections, capacity bumps. These have no latency requirement overnight and belong in a queue with a business hours service level, not on a pager.

The second is triage of alerts that nobody intends to act on. If a page arrives and the documented response is to wait and see whether it resolves, the alert should be a ticket or should not exist. Every page of this kind trains the responder to treat the next page as probably nothing, and that training is the mechanism by which a real page gets a slow response six months later.

The third is being the escalation path for other teams' questions. A rotation that answers "who do I ask about X" is a help desk with a pager attached, and the volume will grow until it crowds out the incidents the rotation exists for. The fix is a documented ownership map and a chat channel with business hours expectations, not a person awake at two in the morning answering routing questions.

Primary, secondary, and what the second person is for

Most rotations have two positions, and teams frequently get the second one's purpose wrong. The secondary is not a second opinion and not a reviewer. The secondary exists for exactly two situations: the primary did not acknowledge within the target, and the primary has acknowledged but needs a second pair of hands for an incident larger than one person.

Written that way, the secondary's quality of life is very different from the primary's. A secondary who is paged on every incident by convention is effectively a second primary, and staffing two primaries for the same scope doubles the cost of the rotation without halving the load on anybody. A secondary who is paged only on timeout and escalation is woken perhaps once a quarter, which is a shift most people can carry alongside normal work.

The automatic escalation on timeout is what makes the arrangement honest. Without it, the secondary's job is to notice that the primary has not responded, which requires the secondary to be watching, which means they are effectively on call anyway. With it, the secondary can sleep, and the system guarantees the response.

The follow the sun question

Organisations with engineers in several time zones frequently ask whether to run one rotation per region so that everybody works daylight hours. When it can be done it is clearly better for the people involved, and it is usually harder than it looks.

The requirement is not merely having staff in three regions. It is having, in each region, enough engineers who can own the same scope: who know the systems well enough to act, have the access to act, and have the authority to make a decision that costs money or breaks something else. A region with two engineers who have read the runbook but never deployed the service will escalate every incident back to the original team, which produces a worse outcome than a single rotation because the escalation adds twenty minutes.

The honest intermediate position, which many teams land on, is a single rotation with a shifted handover so that the worst hours are shared rather than always falling on the same people. It is less good than true follow the sun and much better than a rotation where one region permanently absorbs the overnight hours for everybody.

What a rotation costs, honestly

It is worth stating the cost plainly, because rotations are frequently designed by people who are not on them. A primary week with eight overnight pages is not eight interruptions, it is eight nights of degraded sleep, which affects the following working days as much as the nights themselves.

Research on interrupted sleep is consistent enough to plan around: a single awakening with a cognitive task attached costs substantially more than the minutes spent awake, and the effect compounds across consecutive nights. A rotation that pages twice a night for a week does not produce a tired engineer, it produces an engineer who should not be making production decisions by Thursday.

This is the argument for treating overnight page volume as a first class engineering metric rather than an HR concern. It is the number that decides whether the rotation is sustainable, and it is measurable from the paging system without asking anybody how they feel.

Who should be on it

The default answer, that the people who write the service should carry the pager for it, is right for a reason that is often stated badly. It is not primarily about fairness or about motivating people to write reliable code, although both effects are real. It is that the person who wrote the code can act. They can read the stack trace, they know which configuration flag is dangerous, and they have the access to change it.

A separate operations rotation that carries pagers for code it did not write can do three things: restart, roll back and escalate. Those three cover a useful fraction of incidents and nothing else, and the remainder arrive at the owning team anyway, twenty minutes later and with less context.

The practical exception is scale. Below roughly six people a rotation is too thin to be sustainable, which is why small teams merge scopes or share a rotation across two services. Above that, the argument for keeping ownership and paging together is strong enough that splitting them should require a specific reason.