Skip to main content

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.

It cannot see your alerting, and it does not pretend to. There is no integration and no upload — the inputs are your own estimate of your own week, which is the only data this needs and none of which leaves your browser.

Across the whole rotation, not per person. An approximate count is fine.

How many people share on-call duty.

hours

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.

hours

Optional. Places you in the DORA recovery bands. Zero to skip.

Runs in your browser · nothing is sent anywhere

Pages per shift
3.2
target 2
Versus threshold
1.6×
Google SRE
Pages that led to nothing
36
per week
Lost focus
17.3h
per week · extrapolated
  • worth fixing

    About 3.2 pages per shift — 1.6× the reference threshold

    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: 2 pages per 12-hour shift — Google SRE practice

  • 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: at least 30% actionable — signal-to-noise audit guidance

  • 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: acknowledgement is slower, the responder has less context, and sleep interruption carries a recovery cost that 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.

    Measured against: 8–15 minutes median after-hours acknowledgement — PagerDuty survey, 2023

  • worth fixing

    Roughly 17.3 hours a week of lost focus across the rotation

    Applying the measured cost of regaining focus after an interruption to the page count. This is the figure that makes the case in a planning conversation, because it converts a complaint into a number — but read the caveat below before quoting it.

    Measured against: 23 minutes to refocus after an interruption — Gloria Mark, UC Irvine — general knowledge work, not pages specifically

  • sustainable

    Incident recovery in the High band (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 incident-recovery tiers

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 lost-focus figure is an extrapolation, not a measurement of your team. The 23-minute refocus cost was measured for general knowledge-work interruptions rather than for pages specifically, so treat it as an order of magnitude for making a case, not as a finding.
  • Thresholds are other people's published figures, cited above. They are reference points from organisations with 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:

  • Two pages per 12-hour shift comes from Google’s SRE practice. The reasoning behind it is not comfort — it is that an engineer should have time to investigate each page properly, and beyond a couple per shift that becomes arithmetically impossible.
  • 30–50% actionable is the band healthy alerting systems tend to sit in. 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.
  • 23 minutes to regain focus after an interruption is Gloria Mark’s work at UC Irvine. It was measured for general knowledge-work interruptions rather than for pages, so applying it here is an extrapolation — useful for an order of magnitude, not a measurement of your team.
  • Recovery tiers are DORA’s: elite under an hour, high within a day, medium one to seven days, low beyond 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