Alert Fatigue Across Time Zones: Why the Same Page Costs Different People Different Amounts

Most on-call tooling treats every page as an identical event: it fires, someone acknowledges it, the incident gets logged, and the rotation dashboard shows the same one unit of "an alert" regardless of when it happened. That accounting is wrong in a way that matters for a distributed team specifically — a page during working hours and the identical page at 3am cost the person on the other end wildly different amounts, and a rotation that doesn't account for that difference will look perfectly fair on paper while quietly wearing down whoever's time zone keeps drawing the overnight slot.

This is a different problem than coverage design

It's worth separating this from the coverage question covered in follow-the-sun on-call for small teams — that piece is about whether you have enough time zone spread to avoid waking anyone at all. This one assumes you don't, or won't for a while, and asks a narrower question: given that some pages will land overnight for somebody, how do you measure that cost so the rotation actually distributes it fairly instead of just distributing turns evenly by the calendar?

A cost-weighted alert formula

Borrowing the same logic as pricing out a recurring meeting in real dollars, a page can be assigned a cost multiplier based on where it lands in the responder's local day, not just whether it happened:

A rest-hour page isn't just inconvenient the way a fringe-hour page is — it costs a full night's sleep, which degrades the next day too, so weighting it several multiples higher than a working-hours page reflects the real cost rather than the nominal one. The exact multipliers matter less than tracking cumulative weighted cost per person over a rolling window (30 or 90 days works well), rather than just counting raw page totals or whose turn is next.

Why raw page counts hide the real problem

A four-person rotation split evenly by turns looks fair on a dashboard that just counts pages per person. But if the team spans San Francisco and Berlin, and incidents cluster around a specific batch job that runs at 14:00 UTC, that's 6am in San Francisco and 3pm in Berlin — structurally a rest-hour page for one person and a working-hours page for the other, every single time, regardless of whose "turn" it nominally is. Equal turn counts and equal cost are not the same thing, and only the second one predicts who actually burns out.

What to do with the weighted number

• Rebalance rotation length, not just order. Someone who's absorbed disproportionate rest-hour cost over the last month goes on a shorter or delayed next shift, not just the next slot in sequence.
• Fix the source, not just the rotation, when cost clusters on one trigger.A recurring alert that reliably lands in one region's rest hours — like the 14:00 UTC batch job above — is often a scheduling problem, not a staffing problem; moving the job or tightening its alerting threshold can remove the cost entirely instead of just redistributing it.
• Compensate rest-hour pages explicitly, whether in pay, time off in lieu, or an explicit later start the next day — treating them as free because the person was "already on call" undercounts what they actually cost.

Setting this up

1. Tag every page with the responder's local hour at the time it fired, not just the UTC timestamp most tools default to.
2. Apply a working/fringe/rest multiplier and track the rolling weighted total per person, not raw counts.
3. Review the weighted totals monthly alongside the rotation schedule, and rebalance before someone's cumulative cost gets far out of line with the rest of the team.
4. If one time zone in the rotation is absorbing most of the rest-hour weight structurally, treat that as a coverage-design problem and revisit whether a different coverage model is worth the headcount it requires.