On-call burnout is an alarm configuration problem, not a headcount problem

The instinct when on-call burnout shows up is to hire. Add a fourth person to the rotation, spread the pages thinner. It helps for a month, then the same alarms fire just as often, now against four people instead of three, and burnout creeps back. Burnout isn't caused by too few people on rotation — it's caused by too many pages that didn't need a person at all.

What actually causes on-call burnout?

On-call burnout is the result of a low alert-to-action ratio sustained over time: engineers get paged repeatedly for things that don't require action, and their nervous system learns to treat every page as noise before they've even opened the alert. Adding headcount dilutes the frequency per person but doesn't fix the ratio — the fix is reducing pages that aren't actionable, not spreading them out.

The alert-to-action ratio: the one number that predicts burnout

Alert-to-action ratio = alerts that led to a real fix or genuine investigation, divided by total alerts sent. Below 50%, more than half of every page is noise — engineers learn within weeks that most pages don't matter, and start responding slower to all of them, including the real ones. Above 80%, on-call feels earned: most pages mean something.

You don't need a fancy tool to compute this — pull your paging tool's alert history for the last 30 days and tag each one "actioned" or "no action taken" based on whether the on-call engineer did anything beyond acknowledging it. Most teams have never actually done this exercise and are surprised by the number.

The five alarm anti-patterns that cause burnout

• Static thresholds on metrics with daily or weekly seasonality — a CPU alarm tuned for peak traffic fires every night during the low-traffic trough, or every Monday morning during the traffic ramp. The fix is usually a time-bucketed baseline or a metric math expression that accounts for the pattern, not a single flat number.
• Symptom alarms with no downstream action — an alarm exists because it seemed prudent to add, but nobody has ever written a runbook step for what to do when it fires. If the answer to "what do you do when this pages" is "look at it and go back to sleep," it's not an alarm, it's a notification that should be a digest.
• Duplicate alarms across layers for one root cause — an ALB 5xx alarm, an ECS task error alarm, and an application-level error tracker alert all fire for the same underlying deploy bug. One incident becomes three pages. Composite alarms or clear ownership of "which layer pages first" collapses this back to one.
• Alarms with no self-heal check — a metric spikes for 90 seconds and recovers on its own before a human even opens their laptop, but the alarm already paged. Without a check that re-verifies the condition before notifying, every transient blip becomes a page.
• No severity tiers — every alarm uses the same notification channel and urgency regardless of whether it's a hard outage or a soft degradation. When "disk is at 70%" pages exactly the same way as "service is down," on-call stops being able to triage by instinct and starts treating every page as equally low-priority.

How to audit your existing alarm setup

1. Pull every alarm's state-transition history for the last 30-90 days (CloudWatch console or DescribeAlarmHistory API).
2. For each alarm that fired, tag it: led to a fix, led to genuine investigation with no fix needed, or no action taken.
3. Compute the alert-to-action ratio per alarm, not just in aggregate — a handful of chronically noisy alarms usually account for most of the damage.
4. For every alarm below a 30% action rate, either raise the threshold, add a self-heal recheck before paging, route it to a digest instead of a page, or delete it outright.
5. Re-run the audit 30 days later. A ratio that improves and holds means the fix worked; one that drifts back down means a new noisy alarm has replaced the old one.

What a verification pipeline does instead of a static threshold

The anti-patterns above share a root cause: a threshold crossing gets treated as equivalent to an incident, with nothing in between. A verification pipeline inserts checks between "metric crossed a threshold" and "a human gets paged" — the same principle whether you build it yourself with metric math and Lambda, or use a product that does it for you.

Nuberio Watch's pipeline is one concrete version of this: every anomaly runs through 9 checks before a page goes out — a self-heal recheck (is the metric still anomalous right now, or did it recover in the last few minutes), an AWS Health check (is this a known AWS-side event), a recent-deploy check (did this correlate with a deploy in the last 120 minutes), a service-quota check, a resource state-change check, a security-finding check against GuardDuty and Security Hub, a flapping check (more than 5 anomalies on this metric in 24 hours routes to a daily digest instead of a page), a TLS certificate-expiry check, and an Inspector vulnerability-finding check. Most of these checks either suppress the alert outright or attach context so the page that does arrive is worth opening immediately.

Frequently asked questions