On-call rotations are sized by whoever is available, not by the load. Five people are on the team, so five people are in the rotation, and one week in five feels survivable in the abstract. Whether it is survivable in practice depends on a number nobody computes, which is how many engineer-hours a week the pager actually consumes.
Google published that arithmetic, along with the three limits it enforces. Those limits are unusually specific, they come from operating some of the largest services in the world, and almost nobody outside Google has checked their own rotation against them.
The six-hour number
Everything in the SRE book's on-call chapter hangs off one measurement: what an incident actually costs. Not how long the outage lasted — how long the engineer is occupied.
Google's figure is six hours, and the definition matters more than the number: "dealing with the tasks involved in an on-call incident — root-cause analysis, remediation, and follow-up activities like writing a postmortem and fixing bugs — takes 6 hours." That is triage through to the fix being merged.
If your number is fifteen minutes, one of two things is true. Either your pages are genuinely trivial, in which case they should be automated away rather than paged. Or you are acknowledging alerts, applying the runbook, and never doing the follow-up — in which case the six hours is still being spent, just spread across the next month by whoever hits the same problem again.
The six hours is what turns a page count into a staffing question. Twelve pages a week is not twelve interruptions; it is 72 engineer-hours, nearly two full-time people.
Three limits, three different failures
Two incidents per 12-hour shift is the noise ceiling. The arithmetic behind it is simply that two incidents at six hours each fill a twelve-hour shift, and anything more means the shift ends with unfinished work that either gets dropped or gets handed to someone who was not there.
The important property of this number is that it does not depend on how many people are in the rotation. Pages arriving in a twelve-hour window are a property of the service. If a service generates four incidents a day, hiring four more engineers changes nothing about that: the person holding the pager still gets four.
Twenty-five per cent of an engineer's time is the load ceiling, and this one is about the team. The full policy is worth quoting because the cap only makes sense inside it: "We strive to invest at least 50% of SRE time into engineering: of the remainder, no more than 25% can be spent on-call, leaving up to another 25% on other types of operational, nonproject work."
The cap exists to protect the engineering half. A rotation that quietly absorbs 40% is not being heroic; it is spending the budget that was supposed to fix the reasons for the pages.
Eight engineers, single site is the floor, and this one is about the individual. "The minimum number of engineers needed for on-call duty from a single-site team is eight" with week-long shifts, and for follow-the-sun arrangements "a reasonable minimum size of each team is six." Below that, the gap between your shifts is short enough that on-call stops being an occasional duty and becomes part of the job description.
Work out your own rotation
calculator · on-call rotation
Is your rotation big enough, or just quiet enough?
share of an engineer's week spent on incidents, by rotation size
same rotation, different page rates
Averages hide the thing that makes on-call hard, which is variance: a quiet quarter and one terrible week produce the same mean as a steady trickle and feel nothing alike. The hours-per-page default is Google's measured figure for a real incident carried through to a postmortem and a fix; if your pages are mostly acknowledge-and-ignore, set it lower and then ask why an alert exists that nobody acts on. The 25% ceiling is a policy from the SRE book, not a law of nature, but it is the most defensible number published by anyone.
The default is a realistic small-company rotation, and it fails on two of the three limits. Twelve pages a week is not an alarming number — it is under two a day. Five engineers is a normal team. And the arithmetic says that team is spending 36% of everyone's week on incidents and needs eight people to fit inside 25%.
Three things to try:
Set hours per page to 1. The load drops to 6% and everything looks fine. This is the configuration most teams believe they are in, and the way to check is to ask how many of last month's pages produced a merged fix. If the answer is "a few", the six hours is real and it is being paid later.
Set sites to 2. Night pages go to zero and the rotation floor drops from eight to six. This is the single biggest quality-of-life change available, and it costs a handover ritual and a second team.
Set pages to 30. The per-12-hour figure goes past 2, and the calculator stops recommending more people — because at that point the rotation is not the problem.
The night-pages column is the one worth showing to whoever decides headcount. At five engineers, each person is woken about forty-one times a year. That is not a rota, it is a reason to leave, and it does not appear on any reliability dashboard.
Hiring fixes two of the three
This is the distinction that makes the conversation productive, because "we need more people" and "we need fewer alerts" are usually presented as the same request and they are not.
If the 25% cap is breached but the per-shift incident count is fine, the rotation is genuinely understaffed and hiring works. If the per-shift count is over two, hiring does nothing for the person holding the pager tonight, and the work is in the alerts.
| Symptom | What it means | What actually helps |
|---|---|---|
| Over 25%, under 2 per shift | Too few people for a normal load | More people in the rotation |
| Under 25%, over 2 per shift | Noisy service, adequate team | Delete alerts, fix the top cause |
| Over both | Both, and they compound | Alerts first: it is faster and it shrinks the other number |
| Under both, people still unhappy | Check the night and weekend split | A second site, or a follow-the-sun handover |
Alert triage is the cheapest intervention on this list and the one that gets deferred. The categories that go first: alerts nobody has acted on in a quarter, multiple alerts for one underlying cause, symptoms of a fault that already has a ticket, and anything that pages on a cause rather than on user-visible impact. Most rotations lose a third of their pages to that list without losing any coverage.
Response times, and why they matter to sizing
One more published number: "Typical values are 5 minutes for user-facing or otherwise highly time-critical services, and 30 minutes for less time-sensitive systems."
This looks like an SLA detail and it is actually a sizing input, because a five-minute response target is a constraint on the on-call engineer's life rather than on their calendar. Five minutes means being within reach of a laptop and a reliable connection at all times — no commute, no cinema, no swimming. Thirty minutes means carrying a phone.
Before defaulting to five minutes, check what it buys. If the error budget can absorb thirty minutes of degradation — and the budget arithmetic will tell you — then a thirty-minute target costs almost nothing in reliability and transforms what the shift feels like. Teams routinely pick the tighter number for services where nobody has ever asked for it.
quick check
Your service generates four incidents per 12-hour shift. You double the rotation from five engineers to ten. What happens?
Incidents in a twelve-hour window are produced by the service, not by the rotation. A bigger rotation means each person is on call less often, so the annual load per engineer halves — but the person holding the pager tonight still takes all four. Only removing alerts or fixing their causes changes that number.
What the arithmetic will not tell you
Averages hide the part that hurts. Twelve pages a week could be two a day or all twelve on Tuesday night. The mean is identical and the experience is not, and it is the bad week people remember and resign over. If you track one extra number, track the worst shift of the quarter rather than the average.
Sleep does not average out. Three night pages in one week is not equivalent to twelve spread over a year; interrupted sleep compounds and the recovery is not proportional. PagerDuty's incident response documentation puts the consequence in the plainest available terms: "If the current on-call comes into the office at 12 p.m. looking tired, it's not because they're lazy. They probably got paged in the night." This is the strongest argument for a second site, and it does not show up in any hours-per-week calculation.
Not everyone in the rotation is equivalent. If two of the eight can actually debug the payment path at 3am, the effective rotation is two, no matter what the schedule says. That shows up as the same people being escalated to on every shift, which is worth measuring directly before congratulating yourself on the headcount.
Compensation is part of the design. The SRE book notes that Google offers "time-off-in-lieu or straight cash compensation, capped at some proportion of overall salary", and that the cap is deliberate: it is "a limit on the amount of on-call work that will be taken on by any individual". Unpaid on-call has no such limiting mechanism, so the load has nothing to push back against except attrition. Where you are, it may not be optional either: the EU's working time directive sets a minimum daily rest period of "11 consecutive hours per 24-hour period", and the Court of Justice has repeatedly had to rule on when stand-by time counts as working time.
The cost of the pages is not the cost of the incidents. The hours in this calculator are the engineer's. What the outages cost the business is a different and usually larger number, and the two together are what justify the work — an hour of downtime often costs more than the quarter of engineering time being argued about.
questions people ask
How many engineers do you need for a 24/7 on-call rotation?
Google's published floor is eight for a single-site rotation with week-long shifts, or six per site for a two-site follow-the-sun arrangement. Above that floor, the load decides: total pages multiplied by hours per page, divided by the rotation, has to come in under 25% of a working week.
How many pages per shift is too many?
More than two per twelve-hour shift, on Google's published ceiling. The reasoning is that an incident takes about six hours of work including the postmortem and the fix, so a third incident in a shift guarantees something gets dropped.
Does adding engineers fix a noisy on-call rotation?
Only half of it. A larger rotation reduces how often each person is on call and how much of their year it consumes. It does not change how many times the pager goes off during a shift, because that is produced by the service. If you are over two incidents per shift, the work is in the alerts.
How much time should on-call take?
No more than 25% of an engineer's time, inside a policy of spending at least 50% on engineering. The cap exists to protect that engineering half, which is where the fixes that reduce future pages come from.
What response time should on-call have?
Five minutes for user-facing, time-critical services and thirty minutes for less sensitive ones are the published values. Check your error budget before choosing the tighter one: five minutes constrains where the on-call engineer can physically be, and often buys reliability nobody asked for.
Should on-call be paid?
There is a structural argument for it beyond fairness: compensation capped at a proportion of salary puts a ceiling on how much on-call any one person will take on. Without that, nothing limits the load except people leaving.
The short version
Multiply your weekly pages by six hours. That is the engineer-time your rotation costs, and it is almost always larger than anyone expected: twelve pages a week is 72 hours, nearly two full-time people.
Divide by the rotation size. Over 25% of a working week and the rotation is understaffed, and the cap matters because it is protecting the engineering time that would reduce future pages.
Then check the number hiring cannot fix: incidents per twelve-hour shift, against a ceiling of two. That one belongs to the service. If you are over it, the next headcount request will not help the person on call tonight, and the work is in deleting alerts nobody acts on.