How to Set Up an On-Call Rotation That Doesn't Burn Out Your Team

Someone has to answer when production breaks at 3 a.m. The question is whether that someone is a well-rested engineer with a runbook and a backup, or the same 2 people who always get the call because nobody else knows the system.

A good on-call rotation spreads that load fairly, makes sure every page deserves to be a page, and gives responders a clear path when they get stuck. A bad one quietly drives your best people to update their résumés.

This guide walks through how to design the schedule, set up escalation, cut alert noise, and handle pay and time off. It works for a 5-person startup team and scales to larger groups.

What an on-call rotation actually is

An on-call rotation is a schedule that says who is responsible for responding to production alerts during each period of time. The on-call engineer acknowledges pages, triages problems, fixes what they can and pulls in help for the rest.

Most rotations have 3 parts:

• A schedule: who is on call, for how long, and when shifts hand over.
• An escalation policy: who gets paged next if the first person doesn’t acknowledge in time.
• Alerting rules: which conditions actually wake someone up, and which just create a ticket.

Teams usually manage all 3 in an incident management tool such as PagerDuty, Opsgenie, Grafana OnCall or incident.io, connected to their monitoring stack. If you are still working out what to monitor, start with our guide to observability vs monitoring.

How many people you need on the schedule

Team size is the single biggest factor in whether on-call is sustainable. Too few people means everyone is on call too often, and nobody gets real time off.

Google’s Site Reliability Engineering book gives useful reference points. It says SREs should spend no more than 25% of their time on call, and that a single-site team needs at least 8 engineers for a primary and secondary rotation with week-long shifts, which works out to roughly 1 week per month each. For teams split across 2 sites, it suggests a minimum of 6 engineers per site.

Most small companies can’t hit those numbers, and that’s fine. Use them as a direction, not a pass/fail test:

• With 4 people, each person is on call 1 week in 4. That’s workable if pages are rare.
• With 3 or fewer, consider limiting after-hours coverage to truly critical services, or sharing a rotation with a neighboring team.
• If one person is the only one who can fix a system, that’s a knowledge risk to fix with documentation and pairing, not a reason to keep them permanently on call.

Key takeaway: Aim for each engineer to be on call no more than about 1 week in 4, with a named backup. If your team is too small for that, reduce what pages after hours before you add more shifts per person.

Choosing a schedule pattern

There’s no single right schedule. The best one matches your team’s size, time zones and how often pages fire.

A few scheduling details make a big difference:

• Hand over on a weekday morning, not Friday evening or Monday at 9 a.m. A Tuesday or Wednesday handover gives the outgoing person time to brief the incoming one.
• Use follow-the-sun if you can. If you have engineers in different regions, letting each cover their own daytime hours removes most overnight pages entirely.
• Publish the schedule weeks ahead and make swaps easy. People have weddings, flights and sick kids.
• Keep new hires off the primary slot until they’ve shadowed a shift or 2 as secondary.

Building an escalation policy

An escalation policy answers one question: what happens if the on-call person doesn’t respond? Without one, a missed page can turn a 10-minute fix into a multi-hour outage.

A simple, effective policy looks like this:

1. Page the primary. Expect acknowledgment within a set window.
2. Escalate to the secondary if there’s no acknowledgment, often after 5 to 15 minutes depending on how critical the service is.
3. Escalate to the team lead or engineering manager if neither responds.
4. Allow manual escalation at any time. The primary should feel free to pull in the secondary or a subject expert without asking permission.

Google’s SRE book describes typical response expectations of about 5 minutes for user-facing or time-critical services and about 30 minutes for less time-sensitive systems. Set your own targets based on your service level objectives; our explainer on SLA vs SLO vs SLI covers how to set those.

For major incidents, define roles in advance: an incident commander who coordinates, a responder who works the fix and a communications lead who updates stakeholders. Your incident response plan is the right place to write those down.

Tuning alerts so every page matters

Alert noise is the fastest way to burn out an on-call team. If people get paged for things that don’t need action, they start ignoring pages, and eventually they miss a real one.

Google’s guidance on monitoring is a good filter. Every page should be urgent, actionable and about a problem users can feel. Alert on symptoms, such as rising error rates or slow responses, rather than causes like high CPU on one server. Its “four golden signals” for user-facing systems are latency, traffic, errors and saturation.

Use these rules when reviewing alerts:

• If it can wait until morning, it’s a ticket, not a page.
• If nobody ever takes action on it, delete it or downgrade it to a dashboard.
• If it fires repeatedly for the same root cause, fix the root cause or group the alerts into one incident.
• Every page needs a runbook link that tells the responder what to check first.

The SRE book also offers a load benchmark: since handling an incident, including cleanup and follow-up, can take hours, it suggests a ceiling of about 2 incidents per 12-hour shift. If your team regularly exceeds that, the fix is reliability work, not tougher people.

Run a short alert review at the end of each rotation. The outgoing engineer lists every page, whether it was actionable, and what should change. Tools in the AIOps category can help group duplicate alerts, but they don’t replace this human review.

Compensation and time off

On-call is real work, even on quiet weeks. You’re limiting where people can go and what they can do. Teams that treat it as free tend to lose people.

Common approaches include:

• A flat stipend per on-call shift or week.
• Extra pay for weekends and holidays.
• Time off in lieu, such as a recovery morning after an overnight page.
• Hourly pay for time spent responding to incidents outside normal hours.

There’s no standard amount, and practices vary widely between companies. What matters most is that the policy is written down, applied consistently and reviewed as page volume changes.

In the US, legal rules also apply to non-exempt (hourly) employees. The Department of Labor’s Fact Sheet #22 on hours worked under the Fair Labor Standards Act says an employee required to stay on call on the employer’s premises is working, while an employee on call at home generally is not, unless added restrictions on their freedom make the time compensable. Time spent actually handling a page counts as hours worked. State laws can add their own rules, so check with an employment lawyer or HR advisor before finalizing a policy. This is not legal advice.

How to set up an on-call rotation step by step

Here’s a practical sequence for a team starting from scratch.

1. List the services that need after-hours coverage. Be strict. Internal tools and batch jobs often don’t.
2. Define severity levels. For example, SEV1 means customers can’t use the product; SEV3 can wait for business hours.
3. Pick a schedule pattern from the table above and decide on handover day and time.
4. Set up an incident management tool and connect it to your monitoring and chat tools.
5. Write an escalation policy with primary, secondary and manager levels and clear time windows.
6. Audit your alerts. Remove or downgrade anything that isn’t urgent and actionable, and add runbook links to the rest.
7. Write a compensation and time-off policy and share it before the first shift.
8. Run shadow shifts so newer engineers learn with backup.
9. Hold a handover at each shift change covering open incidents, recent changes and noisy alerts.
10. Review after incidents using a blameless postmortem and track the follow-up fixes.

Signs your rotation is burning people out

Watch for these warning signs and act on them early:

• The same few people answer most pages, even when they’re not on call.
• Engineers dread their shifts or trade them away constantly.
• Postmortem action items pile up without getting done.
• Pages regularly happen overnight for the same recurring problems.
• People stop reporting minor issues because they don’t want to deal with the follow-up.

If you see these, cut alert volume, invest in reliability fixes and revisit staffing. For individual habits and boundaries, see our guide on how to avoid burnout in tech. It’s also worth reading up on site reliability engineering, which treats on-call load as something to measure and manage.

Conclusion

A healthy on-call rotation comes down to a few habits: enough people on the schedule, a clear escalation path, alerts that only fire when someone needs to act, and fair pay or time off for the burden. Start small, review every rotation and fix the noisiest alerts first. Your team will sleep better, and your customers will notice the difference.

Sources

• Google SRE Book: Being On-Call — team size minimums, 25% on-call limit, response time examples and incident load guidance
• Google SRE Book: Monitoring Distributed Systems — what makes a good page, symptoms vs causes and the four golden signals
• US Department of Labor: Fact Sheet #22, Hours Worked Under the FLSA — when on-call time counts as hours worked