Setting up an on-call rotation for a small engineering team
A sustainable on-call rotation for a small team comes down to four things: enough people in the rotation that nobody is on call too often, alerts that only fire when a human needs to act, a clear handover and escalation path, and compensation that recognizes the cost to people’s evenings. Get those right and on-call becomes boring, which is the goal.
This guide is for teams of four to fifteen engineers running a SaaS product, usually setting up on-call for the first time or fixing one that’s burning people out.
Do you need on-call at all?
Not every product needs someone reachable at 3am. Ask two questions: what happens to customers if the product is down overnight, and would anyone notice before business hours? A B2B tool used during office hours in one region may only need business-hours coverage plus good monitoring. A payments flow, a consumer app or anything customers rely on for their own operations probably needs 24/7 coverage.
Write down the answer as a service level: which hours you cover and how fast you respond. That number drives everything else, including cost.
Rotation shapes that work for small teams
With four to fifteen people, the options are limited by arithmetic. Each shape below assumes one primary on-call person, plus an escalation path.
- Weekly rotation. One person is primary for a full week, handing over at the same time each week. Simple to reason about and the most common shape. With six people, each person is on call roughly one week in six.
- Primary and secondary. The secondary is backup if the primary doesn’t acknowledge within a set time. Doubles the people on rotation each week, so it needs a team of eight or more to stay humane.
- Weekday/weekend split. Separate rotations for weekdays and weekends spread the weekend burden more evenly. Useful when weekend pages are rare but disruptive.
- Follow-the-sun. Teams in different time zones each cover their own daytime. The best option when you have it, but it requires real engineering presence in two or three regions.
- Business hours plus best effort. Someone owns alerts during the working day; overnight alerts go to a small volunteer group with no response promise. Honest for early-stage products with low overnight usage.
Below about five people in a 24/7 rotation, someone is on call too often to sustain it for long. If you’re there, reduce what pages overnight before adding people.
Alert hygiene: the part that decides whether on-call is bearable
Most on-call misery comes from bad alerts, not from real incidents. A page should mean “a human needs to act now, and here is roughly what to do.” Everything else is noise that trains people to ignore the pager.
- Page on symptoms, not causes. Alert on error rate, latency and failed checkouts that customers feel, not on CPU at 80%. High CPU with happy customers can wait until morning.
- Every page needs a runbook link. Even a three-line one: what this means, where to look, how to mitigate.
- Separate pages from tickets. Disk filling slowly is a ticket for the next working day, not a 2am page.
- Review every page weekly. For each one, ask: was it actionable, was it urgent, did the runbook help? Delete or downgrade anything that fails.
- Track pages per shift. If a typical week has more than a couple of out-of-hours pages, treat the alert set as a bug and fix it before anything else.
- Deduplicate. One incident should produce one page, not forty.
Handover and escalation
- Fixed handover time on a weekday morning, not Monday at midnight or Friday evening.
- Written handover note: open incidents, anything flaky, deploys or migrations planned for the coming week.
- Acknowledgement timeout that escalates to the secondary or the engineering lead if a page isn’t acknowledged within a set number of minutes.
- Clear authority: the on-call person can roll back, disable a feature flag or scale up without asking permission. Waiting for approval at 3am adds nothing.
- An incident channel and a simple severity scale so the on-call person knows when to wake others up.
- A postmortem trigger for anything serious, using a standard postmortem template.
Compensating on-call fairly
Being on call restricts your life even when nothing pages: no long drives, no evenings out without a laptop. That cost is real and should be paid for. The common approaches:
- A flat stipend per on-call shift or week, regardless of pages.
- Time off in lieu for out-of-hours work, for example the next morning off after a night page.
- Hourly pay for time actually worked out of hours, on top of a stipend.
- A combination, which is what most fair schemes end up as.
Labor law on on-call pay and rest periods varies by country, and in some places standby time counts as working time. Check what applies where your engineers are employed. Whatever you choose, write it down, apply it consistently, and never make on-call an unpaid expectation buried in a job description.
Tools you need (and don’t)
You need four things: monitoring that can detect customer-facing symptoms, an alerting tool that can page a phone with escalation rules, a shared calendar of who is on call, and a place for runbooks. Dedicated incident management products bundle these well; many monitoring platforms now include basic paging too. Check current pricing pages before choosing, as plans change often.
What you don’t need on day one: complex auto-remediation, a dedicated SRE team, or a status page integrated with everything. Start simple, then add what your postmortems tell you is missing.
Making on-call quieter over time
The best on-call rotation is one where shifts pass with no pages. You get there by fixing causes rather than just responding to them. Every out-of-hours page should produce a follow-up: fix the bug, fix the alert, or improve the runbook.
Much of the noise traces back to deployments. Safer deploys, quick rollbacks and backward-compatible migrations cut incidents dramatically; see zero downtime deployment. If your team is drowning and needs someone to set this up properly, it’s part of my DevOps consulting work. Track time to restore as one of your DORA metrics so you can see whether it’s improving.
Questions
How many people do you need for an on-call rotation?
For 24/7 coverage with a weekly rotation, aim for at least five or six people so each person is on call roughly one week in five or six. With fewer, cut overnight pages to genuinely urgent issues, use business-hours coverage, or share the rotation with another team.
How long should an on-call shift be?
A week is the most common shift for small teams because it’s simple to manage and limits handovers. Some teams split weekdays and weekends. Whatever you pick, hand over on a weekday morning with a written note, not late on a Friday or at midnight.
Should engineers be paid for being on call?
Yes. Being on call limits what people can do with their evenings and weekends even when nothing breaks. Most fair schemes combine a flat stipend per shift with extra pay or time off for out-of-hours work. Check the labor rules in each country where you employ engineers.
How do you reduce on-call alert fatigue?
Page only on customer-facing symptoms that need immediate action, attach a runbook to every alert, send non-urgent issues to a ticket queue instead, and review every page weekly to delete or tune anything that wasn’t actionable. Treat a noisy pager as a bug.
Pager going off more than it should?
In a two-week sprint I’ll audit your alerts and incidents with your team, cut the noise, and ship the fixes behind the worst repeat pages.
GMT+2 · Full EU overlap · US East mornings