DEVOPS-06-004-P · Primer — Sustainable On-Call & Operational Load

The idea in one sentence

On-call is only useful if the humans doing it stay rested, paid fairly, and rare enough to still think clearly when the pager goes off at 3 a.m.

Why it exists

A pager that never stops does not make a system more reliable — it makes the responder worse at responding. Tired people miss obvious causes, fat-finger commands, and eventually quit. So the reliability of your service is capped by the sustainability of your rotation.

The Google SRE book treats this as an engineering constraint, not a wellness perk. Its rule of thumb: SREs should spend at least 50% of their time on engineering; of what remains, no more than 25% on-call and up to 25% on other operational work. The reason is causal — engineering time is what shrinks tomorrow's toil, so if ops eats the whole week, the system's load ratchets up forever and the team burns out. Operational overload is described bluntly as a state where a team "might burn out or be unable to make progress on project work." Burnout here is a failure mode you design against, like any other.

How it works

Four levers keep on-call humane. They reinforce each other.

1. On-call load limits. Cap how often the pager fires per person. Google's target: a maximum of two incidents per 12-hour shift, because handling one incident well — triage, fix, and a blameless postmortem — averages about six hours. Two events fill the shift; a third means someone is cutting corners on the postmortem, which is exactly the corner that prevents the next page.

2. Enough people. Load limits only hold if the rotation is staffed. For a single-site team the practical minimum is eight engineers (primary plus secondary, week-long shifts, so each person is on-call roughly one week a month). Split across two sites, a reasonable minimum is six per team. Too few people and the math forces everyone onto the pager too often.

3. Compensation and fairness. On-call is real work outside normal hours, so it should be recognized. Google offers time-off-in-lieu or straight cash, capped at some proportion of salary. The cap is deliberate: it removes the incentive to hoard shifts for money and instead rewards spreading the load evenly. Fairness means night, weekend, and holiday coverage — the heavy shifts — are shared, not quietly dumped on the newest or most junior person.

4. Follow-the-sun coverage. When you have teams in multiple time zones, hand the pager off at the end of each region's business day. A team in Sydney covers its daytime, then passes to Europe, then to the Americas — so no one works overnight. This is the cleanest way to get 24/7 coverage without asking anyone to lose sleep, which is why global teams reach for it.

Watch for burnout signals the way you watch dashboards: rising incident counts per person, stalled project work, postmortems that only patch the specific rollback instead of the root cause, and "we don't own that" appearing around critical components. When those show up, the fix is to reduce load — return operational work to a dev team, embed an engineer to automate away the toil — not to just tell people to push through.

The one gotcha

Follow-the-sun and multi-site rotations fail silently if handoffs are sloppy. A page that lands on the wrong region, or context that never got written down at the shift boundary, means the "always-awake" team is actually a team that keeps waking the previous region up anyway. Coverage on paper is not coverage in practice — the handoff itself must be automated and explicit, or you get the burnout of night shifts plus the confusion of a dropped baton.

See it — the sustainability loop

flowchart TD
    A["Cap load:<br/><= 2 incidents<br/>per 12h shift"] --> B["Staff enough:<br/>>= 8 single-site,<br/>>= 6 per multi-site"]
    B --> C["Follow-the-sun:<br/>hand off at end<br/>of local day"]
    C --> D["Compensate fairly:<br/>time-off or cash,<br/>capped"]
    D --> E["Watch burnout signals:<br/>stalled projects,<br/>shallow postmortems"]
    E -->|"signals rising"| F["Reduce load:<br/>automate toil,<br/>return ops work"]
    F --> A
    E -->|"healthy"| A

The one-line takeaway

Reliability is bounded by the well-being of the people on the pager, so limit incidents per shift, staff the rotation deeply, pay for the burden fairly, and hand off across time zones instead of stealing sleep.

Where you'll meet it

You'll meet this when a new service adds a pager rotation and someone asks "how many people do we need?" — the answer flows straight from the load limits above. You'll meet it in rotation tools (PagerDuty, Opsgenie, incident.io) where you configure shift length, escalation, and follow-the-sun schedules. And you'll meet it in the quiet moment when a strong engineer hands in their resignation citing "too much on-call" — the signal you were supposed to catch three months earlier.

Named concepts: on-call load limits, compensation and fairness, burnout signals, follow-the-sun coverage