Page Budget

Most on-call rotas have a page volume and no target. Volume is treated as a fact about the system, and the response to a rise in it is endurance. Without a stated ceiling there is nothing to breach, so there is never a moment at which page volume becomes work.

A page budget makes it a managed quantity. The widely used figure, from Google's SRE practice, is no more than one or two incidents per 12-hour shift, chosen so that a responder can actually investigate each one - write the timeline, find the cause, file the follow-up - rather than acknowledging and going back to sleep.

Why it matters

Noise has a mechanism, not just a mood. A responder receiving 40 pages a week of which 5 matter learns, correctly, that a page probably does not need reading. That learned response is what causes the real page to be missed, and it is a rational adaptation to a badly set threshold rather than a failure of diligence.

The second cost is capacity. A night page costs far more than the time it takes: the following day is largely lost, and the effect compounds across a rota. The third is attrition, which is the most expensive and the least attributed, because people leave months after the pages that caused it.

Implementation patterns

• Declare the number and report against it weekly, per service, next to delivery metrics where the people who allocate work will see it.
• Delete before tuning. Any alert that has fired more than a few times in a quarter without producing an action is deleted or downgraded to a ticket. This is fast and typically removes most of the volume.
• Page on symptoms, ticket on causes. One symptom alert - error rate, latency, a failing journey - replaces a dozen cause alerts on CPU, disk and queue depth, and fires only when something is actually wrong.
• Fix the top generator with dedicated time. The noisiest service gets a week of engineering, prioritised over features, with page count as the acceptance criterion.
• Check the distribution, not just the mean. A median of two pages a week with one engineer taking twenty is a rota problem wearing an alerting problem's clothes.
• Tie it to an error-budget policy, so exceeding the budget has a defined consequence rather than a sympathetic conversation.

Industry example

Google's published SRE practice is the origin of the specific figure and, more usefully, of the reasoning: the limit is derived from what a human can genuinely process in a shift, not from what a system happens to emit. The number is a constraint on the system, not a description of it, which is the entire shift in stance that makes it useful.

Failure scenarios

• Acknowledgement without reading, the adaptation that precedes every missed incident.
• Alert suppression tools deployed to make the volume bearable, which removes the pressure that would have fixed the cause.
• A second on-call site funded before alert hygiene, exporting the noise and breaking the feedback loop that made anyone fix it.
• Budget declared and never reported, so it has no effect.
• Pages redefined as tickets to meet the number, with the work still done at night.
• A rota grown to spread the load, which burns more people rather than fewer.

Trade-offs

Deleting alerts trades a theoretical detection against a real cost, and the objection is always "but what if". The honest answer is that an alert nobody acts on is already not being acted on, and that the detection it provides is imaginary. That said, the deletion pass does occasionally remove the alert that would have caught something, which is why symptom alerts must be in place first: move coverage to the user-visible layer before removing coverage from the cause layer.

Symptom alerts also cost investigation time. "Checkout is failing" says less about what to do than "queue depth is 9000", so runbooks and dashboards have to carry that load.

When not to use it

A team on a system with genuine round-the-clock criticality and a small, already-actionable page volume does not need a budget; it needs staffing. And for a service in its first weeks of production, page volume is information rather than noise, so apply the budget once the alert set has stabilised, typically after a quarter, rather than suppressing signal during the period when it is most useful.

Interview question

Q: A team takes 40 pages a week, 5 of them actionable, and two engineers have resigned. Leadership offers funding for a second on-call site. What do you tell them, and what do you do in the first two weeks?

What a strong answer covers: that 88% noise moved to another time zone is still noise, with the ownership loop broken · deleting non-actionable alerts and moving to symptom-based paging as the first two steps, which cost almost nothing · a declared target of one to two pages per 12-hour shift, reported weekly · dedicating engineering time to the top generator · checking the distribution across engineers before diagnosing · and the organisational point that the prioritisation system produced this and will reproduce it.

Quick check

Quiz: What is the standard page budget and why that number? One to two incidents per 12-hour shift, because it is what a responder can genuinely investigate rather than merely acknowledge.

Flashcard: First move on a noisy rota? Delete every alert that fired without producing an action, before tuning anything.