To reduce pager fatigue, cut the volume of pages that reach a human, route only actionable alerts to the on-call engineer, and build a rotation that respects sleep, recovery, and fair distribution of load. The single most effective lever is not a better paging tool. It is ruthless alert curation: if a page does not require a human to act within minutes, it should not page. Everything else in this post builds on that principle.
Pager fatigue is the slow erosion of an on-call engineer's ability to respond, caused by too many alerts, too many false positives, and too little recovery time. Left unaddressed, it drives attrition, slower incident response, and missed critical signals buried under noise. Below I lay out a practical approach my teams use to design an SRE pager rotation that people can actually sustain.
What Causes Pager Fatigue
Before fixing the rotation, understand what is actually waking people up. In my experience, pager fatigue rarely comes from a single bad alert. It accumulates from several sources at once.
- Non-actionable alerts. Pages that inform rather than demand action. "CPU at 80%" with no user impact is a classic offender.
- Flapping and duplicate alerts. One incident that fires five separate pages because five monitors trip independently.
- Low-severity alerts routed as high-severity. Warning-level conditions paging at 3 a.m. instead of landing in a queue for business hours.
- Poor rotation design. Rotations that are too long, too frequent, or that give no daytime handoff after a rough night.
- Missing runbooks. Even a legitimate page becomes exhausting when the responder has to reverse-engineer the system every time.
The goal is to attack the volume first, then the structure. Reducing alerts is where you get the largest, fastest return.
Reduce Alerts Before You Redesign the Rotation
You cannot schedule your way out of a noisy monitoring stack. Start by auditing what pages today.
Classify every alert by actionability
Pull the last 30 to 90 days of pages and sort each into one of three buckets:
- Page (act now): user-facing impact or imminent failure requiring human intervention in minutes.
- Ticket (act soon): real but not urgent. Route to a work queue reviewed during business hours.
- Delete (act never): informational, redundant, or chronically ignored.
In most audits I run, a large share of alerts fall into buckets 2 and 3. Move them out of the paging path immediately. A useful rule of thumb: if the on-call engineer consistently acknowledges and closes an alert without taking action, it should not page.
Alert on symptoms, not causes
Page on what the user experiences, not on every internal metric that might contribute. This is the core of the Google SRE guidance on symptom-based alerting (see the SRE Workbook, "Alerting on SLOs"). A single symptom-based alert replaces dozens of cause-based ones.
# Prometheus: page on user-facing symptom (error budget burn), not raw CPU
groups:
- name: checkout-slo
rules:
- alert: CheckoutHighErrorRateFastBurn
expr: |
(
sum(rate(http_requests_total{job="checkout",code=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="checkout"}[5m]))
) > (14.4 * 0.001)
for: 2m
labels:
severity: page
annotations:
summary: "Checkout error budget burning fast"
runbook: "https://runbooks.internal/checkout-error-rate"
The 14.4 multiplier here is a fast-burn threshold against a 99.9% SLO. It pages only when you are consuming error budget quickly enough to matter. Slow burns route to a ticket, not a page.
Deduplicate and group related alerts
Configure your alert manager to group alerts by incident so one outage produces one notification, not ten.
# Alertmanager: collapse related alerts into a single page
route:
group_by: ['service', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- matchers: [ 'severity="page"' ]
receiver: 'pagerduty-oncall'
- matchers: [ 'severity="ticket"' ]
receiver: 'ticket-queue'
group_wait gives correlated alerts a short window to arrive together. repeat_interval stops the same unresolved condition from re-paging every few minutes.
Design an SRE Pager Rotation People Can Sustain
Once the noise is under control, the rotation structure determines whether on-call is tolerable or corrosive.
Size the rotation correctly
A healthy rotation needs enough people that any individual is on-call infrequently and gets real recovery between shifts.
- Aim for a minimum of six to eight engineers per rotation. Fewer than that and shifts come around too often to recover.
- Keep primary shift length to one week or less. Longer shifts compound sleep debt.
- Always run a secondary (escalation) tier so a missed page or an overwhelmed primary has backup.
If a team is too small to staff a humane rotation, that is a signal to consolidate services, share coverage across teams, or bring in a managed SRE partner. Our approach to that is described on the managed services and SRE capabilities page.
Protect sleep and recovery
Being paged at night has a measurable cost that carries into the next day.
- Grant post-incident recovery time. If someone is paged repeatedly overnight, they should not be expected to ship features the next morning.
- Consider follow-the-sun coverage if you have engineers across time zones. Handing the pager to a waking region eliminates most overnight pages entirely.
- Cap concurrent responsibilities. An on-call engineer's primary job that week is being on-call. Do not also load them with sprint commitments.
Make handoffs explicit
A weak handoff turns the incoming engineer's shift into a mystery. Standardize it.
## On-call handoff — 2025-06-09
- Open incidents: INC-4821 (checkout latency, mitigated, monitoring)
- Recent changes: payments-svc v2.14 deployed Fri, watch error rate
- Silenced alerts: DiskUsageWarn on cache-03 until 06-11 (ticket JIRA-902)
- Known noisy alerts: none currently
Build an Incident Response Workflow That Reduces Load
A good rotation still fails if the underlying incident response workflow forces every responder to start from zero.
Every page needs a runbook
The alert annotation should link to a runbook that explains what the alert means, how to confirm the impact, and the first three remediation steps. If an alert has no runbook, either write one or question whether it should page at all.
Track and review pager metrics
Measure the health of your on-call program the same way you measure services. Useful metrics include:
- Pages per shift, especially overnight pages.
- Percentage of pages that were actionable.
- Mean time to acknowledge and resolve.
- Repeat offenders: which alerts fire most often.
Review these numbers in a recurring operational review. When one alert dominates the noise, fix the underlying issue or retune the threshold. This closed loop is what keeps pager fatigue from creeping back after your initial cleanup.
Run blameless postmortems that feed alert tuning
Every significant incident should produce action items, and some of those items should target the paging path itself: add a missing runbook, silence a redundant alert, or adjust a threshold that proved too sensitive. The postmortem is where alert quality improves over time.
Putting It Together
A sustainable on-call program follows a clear sequence:
- Audit and cut alerts. Delete non-actionable pages, route non-urgent ones to a ticket queue.
- Alert on symptoms and SLO burn, not raw resource metrics.
- Deduplicate and group so one incident equals one page.
- Size the rotation for infrequent shifts and real recovery.
- Standardize handoffs and runbooks.
- Measure pager health and feed it back into tuning.
These practices apply across sectors, from fintech platforms with strict uptime obligations to the healthcare and logistics systems we discuss across the industries we support. The specifics of thresholds and staffing change, but the principle holds: page a human only when a human must act, and give that human the structure and rest to respond well.
FAQ
What is the fastest way to reduce pager fatigue?
The fastest lever is alert curation. Audit your last 30 to 90 days of pages, and move every non-actionable or non-urgent alert out of the paging path into a ticket queue. Most teams find a significant portion of pages require no human action, and removing them delivers immediate relief before any rotation changes.
How many engineers should be in an SRE pager rotation?
Aim for at least six to eight engineers per rotation with primary shifts of one week or less, plus a secondary escalation tier. Smaller rotations bring shifts around too frequently and prevent proper recovery. If your team cannot staff this, consolidate services or extend coverage across teams or time zones.
Should I alert on CPU and memory usage?
Generally not as pages. Resource metrics are cause-based signals that often fire without user impact. Page on symptoms such as elevated error rates or SLO error-budget burn. Keep resource metrics as dashboards or ticket-level alerts you investigate proactively rather than at 3 a.m.
How do I know if my on-call program is healthy?
Track pages per shift (especially overnight), the percentage of pages that were actionable, time to acknowledge and resolve, and which alerts fire most often. Review these regularly. A rising overnight page count or a low actionability percentage are early warnings that pager fatigue is returning.
What belongs in a good runbook?
A runbook should explain what the alert means, how to confirm real user impact, and the first concrete remediation steps. Link it directly in the alert annotation. If an alert has no runbook and no one can write one, that is strong evidence the alert should not page.
Production-grade cloud, software, and engineering teams for scaling companies.
