SRE
Is this rotation sustainable?
“We get too many alerts” is an argument, and arguments lose to roadmaps. “This is six times the Google SRE threshold and costs the team roughly eleven hours of focus a week” is a different kind of statement — it can be checked, and it can be put in a planning document.
That conversion is the only thing this page does. You bring the numbers, it does the arithmetic, and every threshold it compares against is somebody else’s published figure with the source attached.
Across the whole rotation, not per person. An approximate count is fine.
How many people share on-call duty.
Hours per on-call shift. 12 and 24 are the common ones.
Your estimate. If you have not counted, the real figure is usually lower.
Nights and weekends.
Optional. Compared with DORA's failed-deployment recovery times. Zero to skip.
Runs in your browser · nothing is sent anywhere
- Pages per shift
- 3.2
- ceiling 2
- Versus threshold
- 1.6×
- Google SRE book
- Pages that led to nothing
- 36
- per week
- Until work resumes
- 18.8h
- per week · extrapolated
Findings
- worth fixing
About 3.2 pages per shift — 1.6× the reference ceiling of 2
Above the threshold but within reach of it. Tuning the noisiest few alert rules usually closes a gap this size without any structural change.
What to do Identify the two or three rules producing the most pages and review their thresholds.
Measured against: at most 2 incidents per 12-hour shift — Google SRE book, “Being On-Call”
- worth fixing
20% actionable — roughly 36 pages a week led to nothing
Below this level the rational response to a page is to assume it is noise, and people adopt that response whether or not they admit it. The risk is not the wasted time; it is that the one page that mattered is treated the same way as the others.
What to do Tuning beats staffing here. Adding people to a rotation with a 10% actionable rate distributes the noise without reducing it.
Measured against: 30% actionable — this tool's threshold, not a published figure — Google SRE book, “Monitoring Distributed Systems”: every page should be actionable
- worth fixing
About 15.7 out-of-hours pages a week (3.9 per engineer)
Out-of-hours pages cost more than their count suggests: the responder is woken, starts without context, and the broken sleep does not appear in any dashboard.
What to do Worth asking of each out-of-hours alert rule: does this genuinely need somebody awake, or could it wait until morning as a ticket? Most rotations find several that could.
- worth fixing
Roughly 18.8 hours a week before interrupted work is picked up again
Applying a measured resumption delay to the page count. It is time before the engineer returns to what the page interrupted, not time lost outright — in the study, people did other work in between — so it is a figure for the disruption, and the caveat below applies before quoting it.
Measured against: about 25 minutes before interrupted work is resumed — Mark, Gonzalez & Harris, CHI 2005 — office work, not on-call pages
- sustainable
Recovery time in DORA's High and Medium clusters (under 1 day)
Recovery time is not your constraint. If the rotation still feels unsustainable, the problem is volume rather than resolution speed — which is a different fix.
Measured against: DORA 2024 report, failed deployment recovery time — the closest published measure; DORA does not benchmark recovery from every incident
What this is and is not
- Everything here is arithmetic on the numbers you entered. Nothing is measured from your systems, and this page has no access to them.
- The actionable rate is your estimate, and estimates of it run optimistic — people remember the pages that mattered. If you have not counted, the real figure is probably lower than the one you typed.
- The resumption figure is an extrapolation, not a measurement of your team. The 25-minute delay was measured for office workers' interruptions rather than for pages specifically, so treat it as an order of magnitude for making a case, not as a finding.
- The paging ceiling is the SRE book's, stated per 12-hour shift and pro-rated here to your shift length; a week on call is not fourteen working shifts, so for long shifts the pro-rated figure is generous. The 30% and 50% actionable lines are this tool's own, and the recovery bands are DORA's for failed deployments. All are reference points from particular contexts, not laws — a rotation covering a payments system and one covering an internal tool can reasonably sit in different places.
Where the thresholds come from
Every reference point is cited in the findings above, and worth knowing the provenance of:
- At most two incidents per 12-hour shift is the ceiling in the Google SRE book’s “Being On-Call” chapter. The reasoning is arithmetic, not comfort: an incident takes about six hours of follow-up, so beyond two a shift an engineer cannot investigate each one properly. It is pro-rated here to the shift length you enter, and every page is counted as an incident.
- Actionable pages. The SRE book’s rule is that every page should be actionable. The 30% and 50% lines this tool flags at are its own, not a published figure: below 30%, the rational response to a page is to assume it is noise, and people adopt that response whether or not they would say so.
- About 25 minutes before interrupted work is resumed comes from Mark, Gonzalez and Harris at UC Irvine (CHI 2005). It was measured for office workers, who did other work in between, so it is a delay rather than time lost, and applying it to pages is an extrapolation — useful for an order of magnitude, not a measurement of your team. (The often-quoted “23 minutes” comes from press coverage, not the paper.)
- Recovery times are from DORA’s 2024 report, which measures recovery from a failed deployment rather than from every incident: elite under an hour, high and medium both under a day, low between a week and a month. No cluster sits between a day and a week.
These are reference points from organisations with particular contexts, not laws. A rotation covering a payments system and one covering an internal dashboard can reasonably sit in different places, and the numbers are a starting point for that conversation rather than a verdict on it.
If the numbers come out badly
The single most useful thing to know is that tuning beats staffing. Adding people to a rotation with a 10% actionable rate distributes the noise without reducing it, and it costs you the engineers’ time twice over — once in the pages and once in the rota.
Alert volume is also almost always concentrated. Ranking rules by how many pages each produced and how many led to action usually shows a handful responsible for most of the load, and fixing those changes the shape of the week more than any process change will.
The structural version of the same point: alert on symptoms your users would notice, not on causes you happen to be able to measure. A cause-based alert fires whenever a thing is unusual; a symptom-based one fires when something is actually wrong, which is a much smaller set.
Related
- Error budget calculator — what an availability target actually permits, and the burn rate
- SLO vs SLA — the ordering rule, and why your objective should be stricter
- All tools
What on-call load means
Being on call means being responsible for responding when something breaks outside working hours. The load is how much that actually costs the people doing it: how often they are paged, how often at night, and how often the page turned out to need them at all.
It is worth measuring because the failure mode is gradual. A rotation does not stop working suddenly — people stop trusting the alerts, response gets slower, and eventually they leave.
Using it
Enter your paging numbers and the size of the rotation. The result compares them against published thresholds and says which one each number crosses, rather than producing a score.
Take the numbers from your paging tool over a few months. One quiet month is not evidence, and one incident-heavy month is not either.
What this checks
- Whether a paging volume is sustainable for a rotation of a given size, from the numbers you enter.
What it cannot know
- See your alert history. The share of pages that led to action is your estimate, and the result is only as good as it.
Check it for real
# export last quarter's pages from your paging tool, then count per person per shift
Real counts, split into actionable and not, are the input that makes the assessment mean something. Google SRE book: Being on-call
Where the thresholds come from
The comparisons are to published figures, not to anything measured here. Google's SRE book gives a target of no more than two incidents per on-call shift, on the reasoning that responding properly — investigating, mitigating, writing it up — takes about six hours. The 30–50% band for actionable pages is from the same tradition: below it, people are being woken for things that did not need them, and the alerts stop being believed. DORA publishes failed-deployment recovery times in performance tiers.
These are reference points from other organisations, and your context may justify different ones — a five-person startup and a thousand-engineer platform team are not comparable. What does not vary much is the direction: paging volume is a symptom, so the fix is either removing alerts that never needed a human or repairing what keeps firing them. The error budget calculator is how you put a number on the second argument.
Questions people ask about this
Where do these thresholds come from?
Two are published and one is ours, and the page says which beside each number. The paging ceiling is the Google SRE book's two incidents per 12-hour shift, and the recovery times are DORA's for failed deployments. The 30% and 50% actionable lines are this tool's own; the published rule is stricter, that every page should be actionable. Citing them means “is this sustainable” stops being a matter of whose opinion carries in the room.
What counts as an actionable page?
One where a human had to do something that automation could not. A page that resolved itself, or that the responder acknowledged and closed without acting, is not actionable — and counting those is how a rota looks busier than it is while the real problem, alerts that should not page anyone, stays invisible.
The numbers came out badly. What now?
The page says what each threshold implies, and the honest short answer is that paging volume is usually a symptom. Reducing it means either removing alerts that do not need a human or fixing what keeps firing them — the error budget calculator is a way to argue for the second, because it puts a number on what the unreliability is costing.
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere
Something wrong or out of date? Report it
Tools that go with this
- Error Budget CalculatorWhat an availability target allows, and the burn rate.
- Kubernetes Manifest AnalyzerPaste a manifest. Removed API versions and newer changes (gitRepo, externalIPs, Ingress NGINX), privileged containers, missing limits, absent probes, plaintext secrets — each linked to the failure it causes.