Paging policy: what deserves a page

A page is the most expensive message in your company: it costs sleep, and sleep is what keeps the next incident fixable.

Every alerting setup drifts the same way: someone adds an alert because a thing once broke, nobody ever removes one, and within a year the on-call phone is a noise machine that everyone silences — which means when the real page fires at 2 a.m., it arrives as the eleventh buzz of the night and gets swiped away like the rest. The fix is not better alerting. It is a paging bar: a written policy for what deserves a human, what deserves a business-hours read, and what deserves nothing but a log line.

1. The three response classes — every alert maps to exactly one

• Page — a human wakes up now. Reserved for symptoms that are burning customer trust or money while everyone sleeps.
• Ticket — a human reads it in business hours. This is where most “urgent” alerts actually belong: capacity trends, certificate expiry with 30 days left, replica lag without customer impact.
• Log — nobody reads it until someone asks. Fine for noise you are not ready to delete; dishonest only if you call it monitoring.

The mapping is written down per alert, not decided by whatever severity the monitoring tool defaulted to. An alert with no assigned class is a ticket by default — the burden of proof is on the page, because the page spends a human’s night.

2. The four-question page test

Before any alert earns page status, it must pass all four; three yeses is a ticket with a fast SLA:

• Does it need a human decision now? Not “soon” — now. Backup age growing is a ticket; backups not running is a page.
• Can a human actually fix it now? If the only action is “wait for the vendor” or “wait for the queue to drain,” it is a ticket with a timer, not a page.
• Will ignoring it make it worse? A self-healing blip is a log line. A thing that pages once and burns out if nobody looks is a page.
• Are customers feeling it, or about to? Internal-only degradation with a workaround waits for morning.

3. What a page must carry — and the anti-flap rule

• One page, one symptom. A page that says “CPU > 80%, memory > 85%, disk > 90%, queue > 1000” is four pages wearing a trench coat, and it wakes a human to do triage the alert system should have done.
• Page on symptom, not cause. “Checkout error rate 4%” wakes the right person. “iostat latency high” wakes whoever happens to know what iostat is.
• Runbook link mandatory. Every page links the runbook for its own symptom. A page without a runbook is a riddle at 2 a.m.; write the link or demote the alert. The runbook template takes ten minutes per alert.
• Anti-flap: three pages from one alert inside an hour → the alert is automatically demoted to ticket status pending tuning, and the demotion is announced. The alert is broken, not the on-call — and saying so out loud is what keeps people trusting the pager.

4. The sleep budget (and the repeat-offender rule)

Paging volume is a budget, not a weather report: target under two pages per person per shift, median, not best week. Two enforcement mechanisms keep it honest:

• Repeat-offender rule: any alert that fires at the same hour three weeks running gets tuned or deleted — an alert that wakes the same person every Wednesday is no longer information, it is a subscription.
• Night-page review: every overnight page gets 60 seconds of review at morning handoff: real or noise? The handover template carries the count. Three noisy nights in a month means the bar moved — tighten it.

This is the flip side of the alert fatigue checklist: that page fixes a noisy system; this one decides what the quiet system is allowed to wake you for.

5. Worked example

An 8-person SaaS, two-person on-call rotation. 41 alerts, 19 of them paging, 9 pages per week median, and the on-call had taken to muting the phone after midnight — which is how a real cache-layer outage waited 40 minutes for a customer email. The re-bar took one afternoon: 19 paging alerts → 6 (4 with fresh runbook links, 2 demoted for being unfixable at night), 11 moved to ticket with SLAs, the rest deleted. Six weeks later: 1.4 pages per shift median, 100% of pages had runbook links, and the repeat-offender rule had already killed the “CPU > 80%” alert that had never once correlated with anything. The next real page — a certificate chain break — got answered in three minutes, because the phone still meant something.

6. Metrics

• Pages per person per shift: median ≤ 2 — above that, the bar is broken, not the on-call.
• Pages actionable (fix existed and was done): ≥ 95%.
• Pages with a runbook link: 100% — binary, checked in the monthly sweep.
• Repeat pages within 24h: < 5% — a repeat page means the first response did not hold, and that is an incident question, not an alert question.

Where this fits

The paging bar sits between three siblings: the incident severity matrix decides who leads once a page is answered; the escalation path tiers decide who is woken second; the alert fatigue checklist prunes the volume that never should have paged at all. For the estate behind the alerts — runbooks, access, the audit nobody has time for — book the small-team ops audit & runbook service.

A pair-fire at 14.4x is one of the clearest answers to this page's question: the burn-rate alert means the error budget is being spent fast enough that a human should look now.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $29

Related: the alert fatigue checklist prunes alert volume, the escalation path tiers decide who gets woken next, and the severity matrix decides who leads once they are awake.

Related: the four golden signals — the four golden signals are the four rows most page-worthy alerts come from.