How to Run On-Call Across Timezones

A friend of mine got paged at 3:47am for a disk that was 81% full. Not on fire. Not the kind of thing that pages anyone at a sane hour. But the alert threshold had been set years earlier by someone who'd since left, the weekly rotation happened to land on him, and that rotation had no idea he lived in Berlin while the traffic that tripped the alert was a US-afternoon pattern. So he woke up, squinted at his phone, acknowledged it, typed a note to fix the threshold later, and then lay there for an hour not sleeping. The incident was nothing. The cost was a good engineer losing a night over a graph that could have waited until his morning.

That's the on-call story a lot of distributed teams are quietly living. It's also the exact opposite of the one they could have.

On-call is where distributed teams get a free advantage

Here's the part nobody says out loud. Round-the-clock coverage is expensive and miserable to build when everyone lives in one city. If your whole team is in San Francisco and something breaks at 3am Pacific, someone in San Francisco is getting woken up, because that's the only timezone you've got. Co-located companies pay real money and burn real goodwill running night shifts and rotations designed to cover the hours their people are supposed to be asleep.

A team spread across the planet already has people awake at 3am Pacific. They're in Berlin, or Bangalore, or Sydney, having an ordinary Tuesday afternoon. The coverage a single-office team has to manufacture, you already own, sitting right there in your org chart. Most distributed teams never claim it. They build the same one-timezone rotation they'd have built in an office, bolt it onto a globe-spanning team, and then act surprised when it wakes people at 4am for problems a teammate in another timezone could have handled wide awake.

The whole game is to stop treating your timezone spread as what makes on-call hard, and start using it as what makes on-call humane.

The default rotation ignores the one fact that matters

Walk into most on-call setups and you'll find a rotation that goes down a list of names, a week each, in whatever order the tool spat out. It knows nothing about where anyone lives. So in any given week, roughly a third of your alerts land in the middle of the on-call engineer's night, purely by the luck of when the systems misbehave and where that week's name happens to sleep.

This is the same category of mistake as managing by the green Slack dot: you're optimizing for a signal that has nothing to do with the outcome you actually want. The outcome you want is that when something breaks, the person responding is awake, alert, and not resentful. A rotation built on an alphabetized list produces that outcome by accident, a third of the time at best.

The fix is almost embarrassingly simple once you see it. Map your rotation to daylight. Slice the 24-hour clock into bands and put whoever is having their working day on point for that band. Your Asia-Pacific people cover what would be the Americas' deep night. Europe covers the handoff hours. The Americas cover their own afternoon and evening. Nobody's primary shift lands in their 3am unless you genuinely have a hole in your coverage, and if you do, that hole is now visible instead of hiding inside a rota that looked fair on paper.

Route the page to the daytime, not to the expert

There's a second failure hiding underneath the first, and it's the one that actually keeps people up. Even with a daylight-mapped rotation, teams route escalations to the person who knows the system best, and that person is frequently asleep.

The payments service acts up. The primary on-call in Sydney takes a look, but the only human who deeply understands the billing reconciliation logic is in Chicago, and it's 2am for her. So either Sydney flails for two hours in unfamiliar code, or somebody escalates and wakes the Chicago engineer for something she'd have fixed in ten minutes at noon. Both outcomes are bad, and both come from the same root: knowledge that lives in exactly one timezone.

You can't solve a knowledge gap during an incident. You solve it in the calm weeks beforehand, by making sure more than one person, in more than one part of the world, can respond to each critical system. That's slow and it feels inefficient right up until the night it saves someone's sleep. Escalation paths should point to whoever's awake and competent, not to the one expert who happens to hold the whole thing in their head. If your escalation policy only works when a specific person picks up the phone, you don't have an escalation policy. You have a single point of failure with a pager.

Handing off a fire is not handing off a task

Sometimes an incident outlives a shift. It's 6pm in Berlin, the database is still limping, and the engineer who's been fighting it for three hours is about to hand the pager to someone whose day is just starting in California. This is a handoff, but it is not the ordinary end-of-day handoff of planned work, and treating it like one gets people hurt.

A normal handoff can be a tidy note written at your leisure. An incident handoff happens under load, with adrenaline, on a problem nobody fully understands yet. The temptation is to dump a link to the alert and say "still looking into it, good luck." That's how the incoming person spends their first forty minutes rediscovering what the outgoing person already knew and threw away.

The thing that has to survive the handoff is the state of your understanding, not just the state of the system. What have you already ruled out. What did you try that didn't work, so they don't waste an hour trying it again. What's your current best guess and why. Where are the dashboards you've been staring at. If you can overlap live for even fifteen minutes on a call while you pass the baton, do it, because this is one of the rare moments where the synchronous cost is obviously worth paying. When you can't overlap, write the running incident log as you go, so the handoff note is a byproduct of the work instead of a thing you have to compose while the fire's still lit.

The runbook decides whether the awake person can act

All of this leans on a quieter piece of infrastructure: the runbook. When the person who's awake isn't the person who built the thing, the difference between a five-minute fix and a two-hour panic is whether someone wrote down what to do.

This is the same argument as writing anything down on a distributed team, pointed at its highest-stakes case. An undocumented recovery step is a landmine you've left for whoever's awake when the expert isn't, and on-call is exactly when it goes off, because the clock is running and the one person who'd know is unreachable. A good runbook doesn't explain the architecture. It tells a tired person at an unfamiliar hour the specific things to check and the specific commands to run to make the pain stop, so they can stabilize first and understand later. Write it the day after each incident, while the memory is fresh, and it compounds. Skip it, and every 3am page is a fresh archaeology dig.

Do the postmortem in writing

After the fire's out, the reflex is to schedule a call so everyone can talk through what happened. On a distributed team that reflex quietly excludes the people who were asleep for the incident, which is often half the team and sometimes the very people who'll be on-call for the next one.

Run the postmortem the way you'd run any meeting some of the team slept through: write it down first. A short document with the timeline, what actually broke, what made it worse, and the concrete changes you're making, readable by someone who wasn't there and won't be awake when you discuss it. Keep it blameless, because the moment on-call feels like a trap where you get blamed for the pager going off on your watch, people stop volunteering for the hard systems and start hiding what they don't know. The point isn't the meeting. It's that the next person who gets paged for this inherits everything you learned instead of learning it again from scratch.

When this genuinely doesn't work

I don't want to pretend the timezone spread is a magic wand. It only pays off if your team actually covers the clock, and plenty of teams don't. If you're eight people in a three-hour band across the US and Europe, you have a real hole from midnight to morning that no clever rotation fills, and you should either accept that some pages wait until someone's awake or be honest that you're asking someone to take night duty. The advantage is real but it's not free. You have to hire into it on purpose, the way you'd make any deliberate choice about your timezone footprint, and you have to build the coverage map before you promise anyone a full night's sleep.

But when the spread is there and you use it, on-call stops being the thing that makes people quit distributed teams and starts being one of the quiet reasons to join one. Nobody dreads the pager the same way when it rings during their afternoon.

Give Every On-Call Handoff a Clock Everyone Reads Right

An incident handoff already happens under pressure, and "I'll take it from 9" means nothing when the two of you are ten hours apart. Timely converts every time mention in Slack to each person's own clock automatically, so a shift change, an escalation window, or a "back online at 14:00 my time" lands correctly whether it's read in Berlin or California, and no handoff gets lost to a misread hour.

Add Timely to Slack — Free · See how it works