cycles
Blog

Cycles Blog

A Lightweight On-Call Rotation for Teams Too Small for PagerDuty

Scope, weighted turns, shift caps, handoff notes, and escalation: a fair on-call rotation a small team can sustain without a paging platform.

A lightweight on-call rotation schedule for teams too small for PagerDuty

The phone buzzes at 3 a.m. because a customer's checkout went down, and on a three-person team there is no ops group to catch it, just whoever sleeps lightest. Small teams with customers who don't stop having problems at 5 p.m. drift into informal on-call: the founder by default, or whoever is too polite to silence their phone. The fix is a lightweight on-call rotation schedule the whole team can sustain.

Enterprise paging platforms are built for a different org chart. They sell routing rules, dozens of integrations, and per-seat pricing for problems you mostly don't have, and they say little about the problems you do have: fairness, fatigue, and coverage gaps. That gap is the point. Paging is just the delivery mechanism. The real problem is rotation planning, which is who covers what, how often, and who catches it when they can't. Get the rotation right and a phone call, a text, and a shared note are enough infrastructure. Get it wrong and the best paging platform simply delivers an unfair schedule faster.

Here is the full system: a one-page scope, a weighting scheme for nights and weekends, caps on consecutive shifts, a handoff template, a three-role escalation chain, a build walkthrough in a rotation planner, and a spreadsheet fallback for week one. If you are weighing a PagerDuty alternative for small teams, this covers the half of the decision those platforms leave untouched.

Before you build anything: define what actually wakes people up

The first design decision is not who goes on call. It is what qualifies. Write the scope before anyone touches a schedule.

A hand reaches from under a duvet toward a phone glowing on a nightstand in a dark bedroom at night.
The page is rare. Who it reaches should be decided while awake.

Pages are for customer-down incidents, data at risk, and revenue blocked. A customer emailing at 9 p.m. does not qualify. Neither does an amber warning that has glowed for a week. Those wait for morning, and the scope should say so in a non-goals list: the things that never wake anyone. That list does as much for sustainability as the page list, because it removes the judgment call from a half-asleep brain.

Then set response expectations on each channel. For example: acknowledge within ten minutes by phone, triage within the hour, resolve when resolution is actually possible. Separate the three, or every page becomes an unbounded commitment.

Keep the whole document to one page. The tighter the scope, the more sustainable the rotation, and vague scope is where burnout starts: if anything might page you, you are effectively always on call. A scope that cannot fit on one page will be ignored at 2 a.m., by which point it has already failed.

Weighting nights, weekends, and holidays: the math of a fair on-call rotation

Equal turns are not fair turns. A week that includes a weekend or a night shift asks more of the person covering it than a plain weekday week, and a rotation that counts both as one turn quietly subsidizes whoever draws the plain weeks. Equal-looking rotations drift unfair over time even when nobody breaks the rules.

A person steps away from a weekend board game at home to take a work call beside a closed laptop.
A weekend turn costs more than the calendar shows.

The fix is to give every turn a weight. A plain week is one point. A week covering nights, a weekend segment, or a holiday is two points, and you can push holiday coverage higher if your customers are active on those days. Fairness then means equal points, not equal turns.

Run the arithmetic on a three-person team over six weeks, with weeks three and five containing holidays:

Person

Weeks covered

Turns

Points

Dana

1, 4

2

2

Farid

2, 5

2

3

Mei

3, 6

2

3

On turns alone, perfectly fair. On points, Dana skated through the cycle while Farid and Mei absorbed both holidays. A weighted tally catches that immediately and hands Dana the next premium turn, and over a few cycles the load converges.

Two more rules keep it honest. The person covering two night shifts in a cycle should not also draw weekend turns in the same cycle. And re-tally the points whenever the roster changes, because the math only stays fair if someone actually does it. That re-tallying is exactly the kind of arithmetic tools are for: a rotation planner such as Cycles keeps a weighted count per person and rebalances on every change, where a spreadsheet waits for someone to notice.

Capacity guardrails: consecutive-shift caps and vacation backup

Fairness across one cycle is not enough. The rotation also has to protect people over time, and the tool for that is hard caps.

Pick limits and enforce them. Two kinds worth setting: a cap on consecutive weekends, and a cap on back-to-back on-call weeks, with numbers chosen to fit your roster. The reason is alert fatigue. A responder woken twice in one night is not the person you want making the third decision, and a responder finishing a second consecutive week reads pages with half their attention. Caps also stop the schedule from quietly collapsing onto the one person who never says no.

Vacation needs a plan before it happens. Name a backup for every shift when the schedule is generated, not after the primary's flight boards. Collect blackout dates before the schedule exists, so nobody's beach week gets interrupted by a roster they saw too late. And build buffer for the unplanned: sick days, departures, sudden scope creep. A rotation that only works at full staffing is not a rotation.

Revisit the caps and weights on a cadence. A quarterly rotation review catches drift while it is still cheap to fix.

Handoff notes that actually get read

A rotation lives or dies on what passes between shifts, because the moment coverage transfers is where information dies. The fix is a handoff note at every change, capped at five minutes to write:

Two developers at an office desk exchange a shared on-call phone with its screen dark during a morning shift change.
Everything the next responder needs, handed over in five minutes.
  • Open incidents: what is live, and where it stands.
  • Watch items: things that could become pages tonight.
  • Known broken: acknowledged but not yet fixed.
  • Reach: how to contact the outgoing person, and until what hour they will answer.

The five-minute cap is the whole design. Bureaucratic handoff templates get skipped, and a skipped handoff is worse than none, because the incoming person assumes it happened. Keep the note with the rotation itself, visible to whoever is next, rather than buried in a DM thread the next responder cannot see.

Escalation basics: primary, backup, owner

Tiny teams do not need paging trees with SLA timers. They need one clear, pre-agreed chain with three roles.

The primary on-call acknowledges and triages. The backup takes over if the primary does not acknowledge within an agreed window, say fifteen minutes, and that handoff happens automatically, with no judgment call required at 3 a.m. The owner makes the final decision when the response needs authority: restore now or wait, wake the vendor, tell the customer. Usually the founder, but named, in writing, before the incident.

The time-box matters more than the number. Small-team escalation fails in two opposite ways, everyone awake at 3 a.m. or nobody, and an automatic handoff with a named owner prevents both. None of this needs alert-routing infrastructure. A phone tree and written expectations do the job.

Building the on-call rotation schedule in a rotation planner

With the policy settled, the build is short. In Cycles, the rotation types map directly onto the decisions above.

  1. Strict rotation for primary on-call turns. Round-robin, in a fixed order, so everyone can see weeks ahead when their week comes.
  2. Weighted rotation for nights, weekends, and holidays. Premium turns count for more than one point, and the fairness tally updates itself instead of living in a spreadsheet.
  3. Shuffled rotation for daytime coverage or the backup pool. These turns need flexibility rather than a fixed order; whoever has capacity takes them, and the shuffle keeps the pool honest.
  4. Capacity caps. Consecutive-shift limits are enforced by the tool rather than a manager's memory, so the schedule simply cannot generate a week that breaks the rules.
  5. The who's-next view. Vacation and blackout dates are folded in before the schedule is generated, so anyone can see tonight's coverage at a glance without asking.

The mapping is the argument. Scope, weights, caps, and backup are planning problems, and a rotation planner is built for exactly those.

Week one on a spreadsheet

You can start this week with zero tools. A small team on-call schedule fits in five columns: person, shift type, weight, consecutive count, and backup.

A tired person sits before a laptop facing away from the camera, face lit by the unseen screen in a late-night home office.
Where a spreadsheet breaks: one person, one late night, one edit.

Person

Shift

Weight

Consecutive

Backup

Dana

Week 4, plain

1

0

Farid

Farid

Week 5, holiday

2

1

Mei

Mei

Week 6, plain

1

2

Dana

Week two exposes the problem. Every vacation request forces a re-tally of everyone's weighted points. One departure and the copy-paste cascade begins: weights drift, a cap gets missed, and the person editing the sheet at 11 p.m. becomes a single point of failure. That is not a concession. The spreadsheet's failure modes are, point for point, the feature list of a rotation planner: automatic weighted tally, caps that cannot be violated, PTO folded in before generation. When the manual tallying gets old, the case for the planner has already made itself.

Why local-first matters when your roster is people data

An on-call roster is sensitive in a specific way: it holds names, phone numbers, vacation dates, and a record of who has been stretched thin this month. A local-first planner keeps that data on your devices rather than a vendor's server. Checking tonight's coverage takes no server round-trip; the schedule is simply there.

Offline access is not theoretical in this use case. When the incident is in your own infrastructure, the last thing you want is a planning tool that depends on it. Keep the argument operational: local-first here means the roster opens instantly and loads regardless of what is on fire.

When you actually do need PagerDuty

If your needs outrun a phone call and a shared note, buy the paging platform. This system does not replace it.

Below that threshold, the unsolved problem for most small teams is not paging. It is fair, capacity-aware rotation planning, and the delivery mechanism is a phone call. The system in one paragraph: a one-page scope that separates pages from morning items, weighted turns so nights and weekends count for what they cost, hard caps on consecutive shifts, a five-minute handoff note at every change, and escalation through primary, backup, and owner on a timer.

The same rotation thinking scales down as well as up. A household running a fair home rotation faces the identical question an on-call roster does: what deserves attention next, weighted by what it actually costs. See how Cycles works if you want that fairness math handled for you.