Designing an On-Call Schedule

With two time zones, the goal I'd push for is follow-the-sun, so nobody gets paged at 3am on a regular basis. Each region covers their own daytime, and the pager hands off when their day ends. Concretely: split the six into two groups of three by region. Each region runs a weekly rotation during their working hours. When region A's day ends, coverage passes to region B who is just starting theirs. Overnight pages for region A land on region B, who is awake. That alone removes most of the pain of on-call. I'd also run a primary plus secondary, not primary only. The secondary is the safety net for when the primary misses a page. With three people per region you can do that without crushing anyone: roughly one week as primary and a different week as secondary out of every three. Rotation length: weekly is the usual sweet spot. Daily means constant context switching and bad handoffs. Monthly means one bad month ruins someone and they lose touch with the system between turns. A week is long enough to keep context and short enough to recover. The trade-offs I care about: - Fairness. Load should be even, and the schedule has to bend for PTO and holidays through overrides, not by silently dumping shifts on whoever's available. - Handoffs. Every shift change needs a written handoff: open incidents, risky changes shipping, anything being watched. A follow-the-sun handoff that loses context is worse than one tired person who remembers everything. - Coverage gaps. With only three per region, watch for the case where one person is on primary and there's nobody fresh for secondary. Never schedule the same person as both primary and secondary at once. - Compensation. On-call is work. Whether it's pay, time off, or reduced project load that week, it has to be acknowledged or people quietly resent it. The anti-pattern I'd avoid: a single 24/7 rotation in one region where someone eats overnight pages every shift. With two time zones you've been handed the fix for free, so use it.