On-call rotation best practices come down to protecting people from noise. The sustainable teams run one-week rotations with a clear primary and secondary, escalate automatically when a page is not acknowledged, keep alerts high-signal so 3am pages are real, write runbooks for the common failures, and pay engineers for the disruption. A rotation that wakes people for false alarms burns them out and gets quietly ignored, which is worse than no rotation at all.
On-call is where reliability meets human cost. Get it right and outages get handled fast by someone who knows what to do. Get it wrong and you get alert fatigue, ignored pages, and your best engineers updating their resumes. The difference is rarely the tooling. It is a handful of practices that treat the people carrying the pager as the scarce resource they are.
What is an on-call rotation?
An on-call rotation is a schedule that decides who is responsible for responding to production alerts at any given time. Instead of everyone being woken by every incident, or nobody feeling responsible, one person holds the pager for a defined window and hands it off cleanly at the end. A good rotation names a primary responder, a secondary as backup, and an escalation path to a lead or manager when a page goes unanswered.
On-call rotation best practices
Keep rotations short and predictable
A week is the common sweet spot: long enough to build context on what is happening, short enough that the disruption ends before it grinds someone down. Publish the schedule weeks ahead so people can plan life around it, and never surprise someone into a shift. Predictability is half of what makes on-call bearable.
Always have a secondary and an escalation path
The primary responder will sometimes miss a page: bad signal, deep sleep, a dead phone. A rotation without a backup is a single point of failure pointed at your worst moments. Configure automatic escalation so that if the primary does not acknowledge within a few minutes, the alert moves to the secondary, and then to a lead. Getting the right alert to the right person quickly is its own discipline, the same way routing each request to the person who can actually handle it keeps work from falling through the cracks in the rest of the business.
Protect the pager from noise
This is the practice that matters most. Every alert that pages a human at night must be real, urgent, and actionable. If it is not all three, it should be an email, a dashboard, or nothing. Alert fatigue is the slow killer of on-call: once people learn that most pages are false, they stop trusting the ones that are real. Tune thresholds, delete flapping alerts, and confirm outages before paging. A monitor that re-checks a failure from multiple regions before it wakes anyone cuts a huge share of false pages on its own.
alertping
Fewer false pages, honest escalation
AlertPing confirms every failure from a second region before it pages you, then escalates on the Team plan if the first responder does not answer. Real alerts reach a human in under a minute, and the flaky ones never fire. SMS on every plan.
Write runbooks for the common failures
A page at 3am is not the time to reverse-engineer how the payment queue works. For each alert that can fire, write a short runbook: what it means, how to confirm it, the first three things to try, and who to escalate to. Our runbook template lays out those sections so you are filling in blanks rather than inventing a format. Link the runbook directly from the alert so the responder is one click from knowing what to do. This is what turns a junior engineer's first on-call week from terrifying into merely tiring.
Make handoffs explicit
When the rotation changes, the outgoing person should hand over anything still smoldering: an incident that is resolved but not root-caused, a flaky service being watched, a deploy to keep an eye on. A five-minute handoff message prevents the incoming responder from being blindsided by context they never received.
Compensate people for carrying the pager
On-call is real work that intrudes on evenings, weekends and sleep. Teams that pay for it, whether a stipend, time off in lieu, or both, keep people willing to do it and signal that the disruption is acknowledged. Teams that treat it as a free expectation build resentment and turnover. This is a retention issue disguised as a scheduling one.
The tooling has a cost too, and it scales with the rotation, because the big paging platforms bill per responder. Before you add everyone to the schedule, check what PagerDuty costs per user and what Opsgenie costs per user, since a rotation of eight people can cost more in seats than the monitoring that triggers it.
How long should an on-call shift be?
For most teams, one week is the right length, with a clear handoff at a fixed time and day. Shorter shifts like 24 hours mean constant handoffs and never enough context; longer shifts like two weeks or a month wear people down and stretch the recovery afterward. If your incident volume is high, a shorter primary window with a longer secondary can spread the load. The right answer is whatever lets people fully switch off when they are not holding the pager.
On-call and your SLA
On-call exists to protect a promise. If you have committed to an uptime SLA, your rotation is the human half of meeting it: monitoring detects and confirms the outage, and the rotation makes sure a person who can fix it is reachable in minutes. The two are one system. A fast detection pipeline feeding a slow, unclear rotation still blows the SLA, and a sharp rotation getting paged late by weak monitoring does too. The combined number the two produce is your MTTR, which is the honest scoreboard for whether the rotation is working.
The through-line of every practice here is the same: on-call works when it respects the people doing it. Cut the noise, share the load, write things down, and pay for the disruption, and the pager becomes a manageable part of the job instead of the reason people leave.