Pager-Volume Targets: What's Healthy, What's Burnout

How many pages per shift is normal? What number means the team is in slow burnout? What number means immediate intervention? Concrete targets.

The question everyone asks

"How many pages a week is normal?" The honest answer: it depends on the team. The useful answer: there are bands where teams behave differently, and the bands map cleanly to outcomes.

The reason this question matters more than most metric questions: page volume is a leading indicator of team health. Page volume rising for two months predicts attrition six months later with high reliability. Teams that catch the rise early prevent the attrition; teams that don't, lose people. The cost of NOT measuring is large enough that the imprecision of the metric is acceptable.

The other reason: page volume is a forcing function on engineering priorities. A team with 3 pages/week ships features. A team with 15 pages/week is doing operational work fulltime, even if their leadership thinks they're shipping features. Knowing the volume tells leadership what the team is ACTUALLY doing.

The 5/10/20 rule

Per on-call shift, per engineer:

• Under 5 pages/week: healthy.
• 5-10 pages/week: warning band.
• Above 10/week: burnout territory.
• Above 20/week: emergency intervention required.

The bands aren't arbitrary. They reflect cognitive cost. A page interrupts focus for 30-90 minutes (the page itself plus the recovery time). 5 pages a week means roughly 5 hours of interrupted focus, manageable, not pleasant. 10 pages a week is 10 hours of interruption, already eating into productive time. 20 pages a week is 20+ hours, the engineer is operationally on-call full-time even when "off-call."

The bands also reflect alert quality. Teams with under 5 pages are usually paging for real things; the alerts are well-tuned. Teams with 10+ are paging for noise; alerts are over-broad. Teams with 20+ have lost track of which alerts are real, and the on-caller treats every page with reduced urgency, which means they miss the real ones.

Healthy: under 5

The team responds promptly, the on-call rotation is sustainable, engineers volunteer for shifts. Most pages are real and worth waking up for. Voluntary attrition is in line with peer teams; on-call comes up in retros as a topic but not as a complaint.

How healthy teams keep page volume low: they kill noisy alerts aggressively. Every page that turns out to be noise gets a follow-up: tighten the threshold, add a debounce, remove the alert if it has flapped 5+ times in a quarter. The on-call's first shift task is reviewing yesterday's pages and triaging them, the discipline is what keeps the volume low.

The risk in the healthy band: complacency. Teams below 5 pages stop investing in alert quality because nothing's broken. Six months later they're at 8 pages because new services accumulated alerts and nobody pruned. The discipline of weekly review is what keeps healthy teams healthy.

Warning: 5-10

The team starts to dread the rotation. Voluntary shift swaps decrease. The first signs of "I just acknowledge and ignore" appear. Pager-related comments in retros tick up. People joking about leaving on-call become less joking over time.

The team's behaviour shifts subtly. Engineers stop volunteering for extra shifts. New hires get assigned to on-call faster (because nobody else wants it). Senior engineers start asking about whether they can step off the rotation. The 360 reviews mention "on-call burden" in the open-text feedback.

What to do in the warning band: a single sprint dedicated to alert quality. Not "alert quality as 10% of capacity", a full sprint where the team's primary deliverable is reducing page volume. Most teams find 50%+ noise reduction in one sprint of focused work; that's enough to drop from 8 pages/week to 4, back into the healthy band.

Burnout: 10+

Engineers begin avoiding rotation. Sleep quality measurably degrades. Project velocity drops in the week after rotation. Resignations start showing up at the 6-12 month mark. The team that started the year shipping 12 features per quarter is shipping 6, and nobody quite understands why.

The structural pattern at this volume: the team is operationally on-call all the time. The engineer who's "on-call" handles pages; the rest of the team handles the spillover that the on-caller can't get to. Project work happens in 2-hour chunks between interruptions. Deep work doesn't exist.

The exit from this band requires structural change, not optimisation. Optimising the noisiest alerts won't get you below 10/week if the underlying system is genuinely fragile. You need either to invest in reliability of the underlying services (longer project) or to expand the rotation pool (cheaper but requires hiring or trading work). Tinkering with alert thresholds in this band doesn't move the needle.

What to do at each band

Healthy: nothing structural; just monitor. Weekly review of the previous week's pages, triage anything noisy, keep the discipline. The point is to STAY healthy, not to optimize further.

Warning: top noise sources get a project assigned within a sprint. Specific ownership, specific deadline. The project is sized to reduce volume by 30%+; smaller targets aren't worth the disruption. Re-measure after the sprint; if you're still in the warning band, do another sprint.

Burnout: the rotation pauses for non-critical alerts. The on-call's next sprint is dedicated to alert quality AND structural reliability work. The team's overall sprint goals shift to reflect this, leadership cannot hold the team to the same delivery cadence in this state. Trying to hold the cadence is what produces resignation.

Above 20: leadership involvement required. The team cannot self-extract from this band; the underlying system is likely unfit for production. Common cases: a service that should never have shipped, a vendor dependency that's failing, a single-points-of-failure architecture. The fix involves business decisions (deprecate, replace, escalate to vendor) that engineers alone can't make.

The attrition metric

Voluntary attrition on teams in the burnout band runs ~30% higher than teams in the healthy band, sustained over a year. The ROI on cutting page volume is the cost of NOT hiring two replacements per year.

The attrition is rarely visible early. Engineers don't quit because of one bad week; they accumulate frustration over months and quit when an external trigger arrives (a recruiter, a partner moving, a project ending). By the time the resignation hits, the team has been losing the engineer's engagement for 6+ months.

The leading indicators that show up before resignations. Engineering Manager 1:1s mention on-call as a topic. Voluntary shift swaps decrease. New project ideas decrease (engineers stop proposing things because they don't have bandwidth). Sick days near on-call shifts increase. Each is a soft signal; combined, they predict resignation 3-6 months out.

What to do this week

Three moves. (1) Compute your team's pages-per-week-per-engineer for the last 90 days. Most teams haven't measured this; the number is usually a surprise. (2) Plot the trend by month. The slope matters more than the level, a team at 8 with a flat trend is fine; a team at 4 with a steep upward slope is in trouble next quarter. (3) If you're in warning band or worse, get one sprint of alert-quality work on the next planning. The conversation with leadership is "we are X pages/week, the data says this band predicts attrition; we need a sprint." That conversation is hard to have without the data; with the data, it's a 5-minute decision.