Most small teams set up on-call the same way: they don't. Someone is "kind of" responsible, alerts go to a shared inbox or a Slack channel, and whoever happens to be looking catches the fire. That works right up until the night nobody's looking, and then you learn the hard way that "everyone is on-call" means nobody is.
I've built Tallwatch around on-call and incident response, so I think about this constantly. But the structure here isn't a Tallwatch thing — it's the same shape Google's SRE teams use, scaled down to something a team of three to ten can actually run without a dedicated SRE org. Let me walk through it the way I'd set it up from scratch.
Why a real rotation matters
The point of a rotation isn't bureaucracy. It's two things: making responsibility unambiguous, and making it bounded.
Unambiguous means that at any moment, exactly one named human owns "if production breaks, I respond." Not a channel, a person. Ambiguity is how pages get dropped — everyone assumes someone else has it.
Bounded means nobody is on the hook forever. Always-on responsibility is how you lose your best engineers to burnout. A rotation says: you own it this week, then you genuinely hand it off. Without that handoff you don't have a rotation, you have a permanent assignment with extra steps.
Step 1: Pick a cadence
How long does one person hold the pager before it rotates? Three options, in order of how often you'll want each:
- Weekly — the sane default. One person is primary for a week, then it rotates. Long enough that you're not re-onboarding daily, short enough that nobody dreads it. For most small teams, stop here.
- Daily — for heavy load. If you're getting paged multiple times a night, a week of that is brutal. Google's SRE practice caps sustained on-call load and keeps busy shifts short for exactly this reason (Being On-Call). Shorten the shift — but also treat loud nights as a bug to fix, not a schedule to endure.
- Follow-the-sun — if you're spread across time zones. With people in genuinely different regions, hand the pager to whoever is awake, so nobody gets woken at 3am. This is the dream, but it only works if you actually have coverage across those hours — don't fake it with two people in the same city.
A candid caveat: if you're leaning on follow-the-sun, check how your tooling does the handoff across time zones. Some tools (Tallwatch included, right now) store a person's timezone but don't yet automatically shift the handoff to their local clock. I'll come back to this.
Step 2: Add a secondary
A single on-call person is a single point of failure, and the failure mode is the worst one: the page fires and nobody answers because the one person on duty is asleep, out of signal, or just having a bad night.
So you add a secondary (call it backup). The job is simple: if the primary doesn't acknowledge a page within some window, it goes to the secondary. They're usually quiet — but they're the reason a missed page never just vanishes. This is the single highest-leverage upgrade a small team can make.
Step 3: Escalate when the primary misses
A secondary only helps if something automatically moves the page from primary to secondary. That something is an escalation policy.
The mechanics: you define ordered levels. Level 1 pages the primary and waits, say, five minutes. No acknowledgement? Level 2 pages the secondary. Still nothing? Level 3 pages a wider group, or a louder channel, or the team lead. An acknowledgement at any level stops the cascade.
The reason this exists is human: people miss things. The escalation policy is the safety net that turns "the primary slept through it" from an outage into a thirty-second delay. Build it so that no single person failing to respond can swallow a real page. (More on the channels in which alert channel actually wakes you at 3am — because what you escalate to matters as much as that you escalate.)
Step 4: Overrides for swaps and sick days
Schedules meet reality. Someone's on-call week lands on their sister's wedding. Someone wakes up with the flu and shouldn't be the person making production decisions. Someone wants to trade their Thursday for your Sunday.
If your only option is to rebuild the rotation, people will just quietly not do it — and then the schedule says one thing while reality says another, which is how a page reaches someone who's on a plane. You need calendar overrides: a clean way to say "for these specific dates, this other person covers." The base rotation stays intact; the override handles the exception. Make swaps and sick days a two-click operation, or they won't happen.
Step 5: Write a runbook so the person paged can act
Here's the failure I see most: the page works perfectly, wakes the right person, and then they stare at their phone at 3am with no idea what to do. The page told them something is wrong. It didn't tell them what to do about it.
A runbook closes that gap. It doesn't need to be elaborate — for each common alert, write down: what this alert means, the first three things to check, how to tell if it's actually customer-impacting, and who to wake if it's beyond you. Link it directly from the alert if you can.
The test of a good runbook is simple: could the newest person on your team act on this page at 3am without messaging anyone? If not, you've just moved the bottleneck from "did the page arrive" to "does the person know what to do."
Step 6: Keep it fair, and keep it trustworthy
This is the step that decides whether your rotation survives the year, so I'm spending the most words here.
Fairness. On-call is real work done at unsociable hours, and it should be acknowledged as such. Google compensates out-of-hours on-call and caps it as a deliberate limit on how much any one person carries (Being On-Call). You don't have to copy that exactly, but the principle holds: rotate evenly, cap how often anyone is on, and treat a brutal on-call week as something the team owes back, not something people just absorb.
Trust — and this is the one people skip. The fastest way to destroy a rotation isn't an unfair schedule. It's false pages. If half the alerts that wake your on-call engineer turn out to be nothing — a flaky check, one bad network moment — they'll stop trusting the pager. And a distrusted pager is worse than no pager, because the night a real outage finally fires, they'll assume it's noise again and roll over.
So the health of your rotation depends on something upstream of the rotation entirely: the quality of the signal feeding it. This is why I built Tallwatch to page by consensus rather than on a single failed check — an incident only opens when at least two checked regions agree the target is actually down. One region having a bad hour never reaches your escalation policy at all. Run the most beautifully fair schedule in the world, but if it's drowning in false pages, you're just distributing burnout evenly.
Step 7: Wire it together
Now the tooling, because all of the above is theory until something actually executes it. You need a system that owns the schedule, runs the escalation, and handles overrides without a spreadsheet and a prayer.
This is exactly what Tallwatch's on-call rotations are built for. You set a cadence — weekly, daily, or custom — and it rotates automatically. You add calendar overrides for swaps and sick days without touching the base schedule. And you wire it into escalation policies with up to ten ordered levels, each pointing at channels and/or on-call schedules, each with its own timeout, where an acknowledgement stops the cascade. All of it is included on every plan, including free — on-call isn't gated behind a paid tier, because a team that can't afford a tool is exactly the one that most needs a real rotation instead of "whoever's looking."
Two honest limits, so you set it up with eyes open. First, the time-zone thing: Tallwatch stores each person's timezone but does not yet shift handoffs to their local clock automatically, so if you're running follow-the-sun, mind the handoff times manually for now. Second, Tallwatch has no native phone-call or SMS paging — and a ringing phone is still the most reliable way to wake someone. The fix is to point your critical escalation level at the PagerDuty channel and let PagerDuty place the call. You keep consensus monitoring, rotations, and escalation on Tallwatch, and borrow the one capability we don't ship for the level where it matters most.
That's the whole rotation: a sane cadence, a backup, automatic escalation, easy overrides, a runbook, fairness, and — most of all — a signal worth trusting. Get those right and on-call stops being the thing your best people quietly resent.