Why this matters
On-call breaks quietly. One person answers the night pages for a month, then another, and soon the schedule tells you who feels responsible and who has checked out. A fair rotation makes the load visible. It also makes the load bounded, with a clear handoff and a known path to get help.
Fair does not mean every person takes the same number of shifts. A new engineer may shadow before taking primary. A person in another time zone may cover different hours. What matters is that rules are written, schedules are published early, and no one is surprised. This guide, How to set up a fair on-call rotation, treats on-call as a system you design and review, not a rota you copy from a wiki page.
Before you start
Start with an inventory. List every service that can page, the alerts that fire from it, the owner who can fix it, and the runbook link. Pull the last month of alert history and mark pages that repeat. If a page has no owner or no clear action, fix that before you put a name on a schedule. A rotation around noisy, ownerless alerts burns people out and teaches them to ignore the pager.
Choose the shape of the rotation. One week is common because it gives enough context without trapping someone for a month. Set a fixed handoff day and time. For teams across time zones, decide between follow-the-sun coverage and one shared rotation with a written rule for night pages. Define primary and secondary responders, response times, and what counts as an emergency. Use the paging tool's schedule, override, escalation policy, and calendar sync settings so the schedule is not a spreadsheet edited by hand.
Check access before launch. The on-call person needs logs, metrics, dashboards, deploy history, rollback or feature flag controls, and read access to the data needed to diagnose. They also need a place to post status and an incident channel. Test the secondary responder's access too. A runbook that links to a tool the responder cannot open is not a runbook.
How to do it
Build the rotation in order: policy, ownership, schedule, paging rules, access, shadow shifts, handoff, review. Set a launch date and tell the team what changes. Keep the schedule in the paging tool. Publish overrides and swaps in the same place so there is one source of truth.
Write the policy in plain language. Cover coverage hours, response times, primary and secondary duties, swap rules, handoff expectations, and recovery after night pages. Decide how on-call is recognized: time off in lieu, a paid on-call arrangement, or another method your company already uses. Settle that with finance and HR before the first shift, not after the first bad week.
Do not launch with a full load on day one. Run shadow shifts, then a short pilot with one service or one team. Watch the first two handoffs closely. Fix access gaps and bad pages before you add more services.
- Write the on-call policy. Put coverage hours, response times, primary and secondary roles, swap rules, and recovery time in one short document. Get sign-off from engineering and the people who handle pay or time off. Publish it where the team already looks for process docs.
- Map services to responders. Assign an owner and a backup for each service that can page. Confirm that the backup can diagnose and roll back the service. Leave no service on the schedule without a named owner.
- Build the schedule in the paging tool. Create the rotation with a fixed handoff day and time. Add calendar sync and a visible override process. Set the schedule at least a month ahead so people can plan.
- Set escalation and acknowledgement rules. Define how long the primary has to acknowledge a page before it goes to the secondary. Make the secondary a real responder, not a name on a page. Test the path from alert to human with a drill.
- Prepare access and runbooks. Give every responder the same role-based access to logs, metrics, deploy history, and rollback controls. Link each alert to a runbook that states the first three checks and the escalation contact. Test the links from a phone.
- Run shadow shifts. Pair a new responder with an experienced one for at least one full shift. Let the new person handle pages while the shadow watches. Remove shadow status only after a real or drill incident is handled end to end.
- Use a handoff checklist. At each handoff, review open incidents, recent changes, expiring overrides, and known risks. Record the handoff in the incident channel or a shared note. A five-minute call beats a surprise at midnight.
- Review load every month. Export pages per shift, night pages, escalations, swaps, and acknowledgement times. Compare by person and by service. Adjust the schedule or fix the noisiest alert before the next rotation.
How to check it worked
Pull the shift report at the end of each rotation. Look at pages per shift, night interruptions, escalations to secondary, swaps, and missed handoffs. Compare by person and by service. A quiet service and a noisy one are not equal work, even when the shift counts match.
Ask each responder three questions in a one-to-one: did you sleep, did you have the access you needed, and did the handoff tell you what was going on. The answers matter more than a tidy schedule. If people trade shifts every week, the rotation shape is probably wrong for their lives.
Test the system on a calm day. Page the primary, let the timer run, and confirm the secondary gets it. Open the runbook links from a phone. Check rollback access for the secondary. Do this every quarter and after any tool change.
Check that recovery is real. If no one takes time after a bad night, the policy is either unclear or unsafe to use. Fix that before you call the rotation fair.
Mistakes to avoid
Equal shift counts can hide unfair load. A person on a high-traffic service with weak alerts will carry more interruptions than someone on a quiet service. Count night pages, escalations, and time spent on incidents, then adjust who takes the next turn.
Do not run without a secondary. Do not let the team route every hard page to the same lead. That hero path feels fast and makes the schedule fake. New responders need shadow time, and the secondary needs real access.
Avoid long blocks, last-minute edits, and swaps that live in chat. Publish the schedule early. Keep overrides in the paging tool. If someone swaps, record it so the next handoff and the monthly review see the change.
If your on-call rotation is shaky because releases, environments, and monitoring are still manual, Cloudverg's Delivery platform setup at $14,500 fixed price is one option among others. It takes 4 weeks and starts within 10 business days, and it can give responders a tested rollback path and monitoring they can trust.
Frequently asked questions
How long should an on-call shift be?
One week is a common default because it gives enough context without exhausting the responder. Shorter shifts can work for high-volume services, but they add more handoffs. Pick a length your team can sustain and review it after a month.
How do you make on-call fair when some services are busier?
Schedule by burden, not by head count. Track night pages and escalations per service, then rotate the busy service more often or give the person who covered it a lighter turn next. Fix noisy alerts so the schedule is not carrying a product problem.
Should on-call be compensated?
That is a company policy question, not a technical one. Some teams use paid on-call, some use time off after night pages, and some use both. Write the rule down and make sure managers actually approve the recovery time.