What is Pager Fatigue?

The obvious component is interruption. Overnight pages fragment sleep, and the recovery cost of a 3am page is far larger than the twenty minutes spent resolving it.

The less visible component is anticipatory load. An engineer on-call cannot be far from a laptop, cannot drink at dinner, and cannot fully disengage, and this cost is paid across the entire shift regardless of whether anything fires. A quiet week on-call is still a week not fully off.

It is one of the strongest predictors of attrition on infrastructure teams, and its effects compound before anyone raises them.

• Degraded response: a tired responder makes worse decisions during exactly the incidents that need good ones.
• Attrition: engineers leave teams with punishing rotations, which shrinks the rotation further.
• Reduced throughput: the week after a rough shift is not a productive one.
• Compounding effect: each departure increases load on those remaining.

Reducing alert volume is the highest leverage change, since every unnecessary page is fully avoidable cost. Automating routine remediations removes the pages that require no judgment.

Structural changes matter alongside it: larger rotations, follow-the-sun coverage so overnight pages land in someone's daytime, mandatory recovery time after disrupted nights, and treating any recurring overnight page as a defect with an owner rather than a permanent feature of the rotation.

Alert fatigue is a signal quality problem. Too many alerts do not matter, so responders stop reading them carefully. It is fixed by deleting and redesigning alerts.

Pager fatigue is a human load problem, and it persists even with perfect alerting because the readiness burden is inherent to being on-call. Fixing alert quality reduces it substantially, but rotation size, shift length, and recovery policy are separate levers. A team can have excellent alerting and still burn out a three-person rotation.