An on-call rotation is the schedule that decides who gets paged when something breaks in production, and in what order. Build one for a team that's entirely in-house and the mechanics are simple: pick a cadence, name a primary and a secondary responder, escalate if nobody answers. Build one for a team that includes nearshore or contractor engineers and three questions show up that a single-employer rotation never has to answer: who's allowed to page someone outside your payroll, what you owe them for being reachable, and whether the hours they spend waiting for a page even count as working time under the law where they sit.
What is an on-call rotation?
An on-call rotation assigns responsibility for responding to production incidents to a specific engineer, or a small group, for a defined period: a week, a set of days, a single shift. The engineer on the schedule carries a pager, in the literal or PagerDuty-app sense, and is expected to acknowledge and start working an alert within an agreed response time. A secondary responder backs up the primary if they don't answer, and escalation policies route the alert further up the chain if neither does.
The rotation exists so incident response doesn't depend on whoever happens to be awake and near a laptop. It also spreads the disruption of off-hours pages across the team instead of concentrating it on one person indefinitely. On many teams the duty ends up with the SRE who owns the error budget and runs the rotation, though whoever holds the title, the schedule needs the same structure either way.
Rotation models: weekly, daily, follow-the-sun, primary/secondary
Rotation shapes fall into a handful of patterns. incident.io's breakdown of on-call scheduling models groups them into three core patterns: follow-the-sun, primary/secondary, and a buddy system that pairs a new engineer with an experienced one while they learn the rotation. FireHydrant's list of scheduling models cuts it differently, into four: weekly or alternating-day rotations for small teams, location-based follow-the-sun, responsibility-based, and frequency-based scheduling. The shape that fits depends mostly on team size and how spread out the team is across time zones.
Team size matters more than the model name. incident.io recommends a straightforward primary/secondary split for teams of 5-10 engineers, and a follow-the-sun handoff once a team grows past 10-25 or spans multiple regions. Datadog's guidance on rotation size lands in a similar place from a different angle: aim for 6-8 engineers per rotation so nobody is on-call more than roughly once a month, and keep individual shifts to 8-12 hours so no one is expected to stay alert for a full day straight. Below that headcount, the same two or three people end up carrying every page, and burnout shows up fast.
Follow-the-sun on-call with a nearshore team on CET hours
Follow-the-sun rotation hands off on-call duty to whichever region is in its working day, so nobody in any region is expected to answer a 3 a.m. page. Xurrent's follow-the-sun example uses three offices, London, New York and San Francisco, each covering its own 9-to-5 local day. That model works if you actually staff three locations. A team building a nearshore rotation usually staffs two.
A US company with an engineering team in Poland, Hungary, Slovakia, Serbia, Slovenia, Romania, or Spain isn't running a three-region handoff. It's running a two-region one, US hours against CET hours, with a few hours of overlap in the late US morning and early CET afternoon. That overlap window is where the handoff itself should happen, not at the edge of either team's working day, because a rushed handoff written by someone about to log off is where context gets lost. Build the rotation around the actual overlap, not around a generic 8-hour-block assumption borrowed from a three-region example that doesn't match the team you have.
The CET block also narrows how much genuine "sun" coverage you get from a two-region split. CET sits roughly 6-9 hours ahead of US time zones, which covers the early evening and overnight hours for a US-based team reasonably well but leaves the US team's own daytime hours uncovered by the nearshore side. Map the actual gap in your team's calendar before assuming follow-the-sun eliminates off-hours pages entirely. For a two-region team it usually shrinks the problem rather than solving it outright.
Who can you page when part of the team is a contractor or nearshore engineer?
A rotation schedule defaults to assuming a single-employer team, where every engineer on it reports to the same manager. That assumption breaks the moment part of the rotation is staffed by a vendor or an independent contractor.
Contractors and nearshore engineers can sit on the schedule, and often should: they're frequently the person who wrote the code most likely to page. What needs settling is who has the standing to actually page them, at what hours, and under what terms, and whether that's written down anywhere a contractor's manager could point to if a 2 a.m. page becomes a pattern rather than an exception. A loose verbal understanding that the nearshore team helps with on-call now and then leaves a gap that surfaces the first time someone disputes an invoice line for after-hours work, or the first time a contractor's actual employer of record objects to how often their engineer is being paged.
Put it in the contract or statement of work before the first page goes out: which hours the engineer is reachable, who initiates the page, what response time is expected, and how off-hours response gets paid. That's the same ownership-across-a-company-boundary problem the postmortem that follows the page runs into on the other side of an incident, when an action item needs an owner who doesn't report to the person running the review. Get the on-call terms written down and the postmortem ownership question gets easier too, because the contract already establishes who's accountable for what.
Don't let the arrangement drift into a second, informal process either. The same argument behind running one set of ceremonies for the whole team applies to paging: if nearshore engineers work a separate, unwritten on-call arrangement instead of the schedule everyone else uses, you end up with two processes and no single record of who's actually covering what.
What EU working-time law says about stand-by and on-call time
The Court of Justice of the European Union ruled on this directly in Case C-580/19 (RJ v Stadt Offenbach am Main), decided by the Grand Chamber on 9 March 2021. The Court's official press release on the ruling states it plainly: "A period of stand-by time according to a stand-by system is not, in its entirety, working time unless the constraints imposed on the worker very significantly affect his or her ability to manage, during that period, his or her free time." A loose requirement to be reachable doesn't automatically convert on-call hours into working hours. A requirement that effectively pins someone to their desk, unable to do much else, can.
That's the full extent of what the press release says, and it's worth reading as narrow rather than as a general rule for every on-call arrangement. The Court was interpreting Directive 2003/88/EC (the EU Working Time Directive) on one specific set of facts, and how a national court or labor authority applies that standard to a specific rotation, response-time requirement, or country's implementing law is a separate question this doesn't answer.
It also only applies where EU law applies in the first place. HighCircl staffs engineers from Poland, Hungary, Slovakia, Serbia, Slovenia, Romania, and Spain, and Serbia is not an EU member state. A rotation built around a Serbia-based engineer isn't automatically covered by the CJEU's reading of the Working Time Directive the way a rotation built around a Poland-based or Spain-based engineer would be. If your on-call policy spans more than one of those countries, don't assume one legal answer covers all of them. Check the specifics, including how each country's own labor code treats stand-by and on-call time, with local counsel before you finalize a rotation policy, rather than extrapolating from a single CJEU case decided on German facts.
How to set up an on-call rotation
1. Set the rotation cadence and team size
Decide how often the on-call assignment rotates, weekly is the most common default, and how many engineers sit in the pool. Datadog's guidance of 6-8 engineers per rotation is a reasonable starting target: enough that no one is on-call more than about once a month, few enough that everyone in the pool stays genuinely familiar with the systems they might get paged about.
2. Assign primary and secondary responders
Every shift needs a primary responder and a secondary who gets escalated to if the primary doesn't acknowledge within an agreed window. Write the escalation window down as a number, not a vague expectation, so nobody has to guess how long to wait before paging the backup.
3. Design the follow-the-sun handoff (if the team spans time zones)
If the rotation spans a US team and a CET-based nearshore team, build the handoff around the actual overlap window between the two working days, not an evenly split 8-hour-block assumption. Document what a handoff has to include, open incidents, context on anything flaky in the past 24 hours, anything scheduled that might trigger an alert, so it doesn't depend on whoever's logging off remembering to mention it.
4. Decide who can page a contractor or nearshore engineer, and get it in the contract
Name, in the contract or statement of work, who has the authority to add a nearshore or contractor engineer to the schedule, during which hours, and what response time is expected. Don't let this default to an informal Slack arrangement. Write it down before the first page, not after the first dispute.
5. Set compensation and recovery-time rules before the first page
Runframe's stance on on-call pay is direct: pay engineers for being on-call, regardless of whether they actually get paged, and give recovery time after an off-hours page rather than expecting a full working day right after a 3 a.m. incident. Decide your own position on both before the rotation goes live, and make sure it's consistent across in-house and nearshore engineers doing the same job. Paying an in-house engineer for on-call time while a nearshore engineer on the same rotation gets nothing for the same hours is a fairness gap that surfaces fast on a blended team.
6. Pick and configure the tooling
Whatever paging tool you use, PagerDuty, Datadog's on-call product, incident.io, or something else, configure the schedule, escalation policy, and override rules before the rotation starts, not while the first alert is firing. Confirm every engineer on the schedule, including contractors, actually has the app installed and notifications enabled. An engineer who's technically "on the schedule" but never got added to the paging tool isn't actually covering anything.
7. Review the rotation on a fixed cadence
Rotation schedules drift: someone leaves, a contractor's engagement ends, a team grows past the size the original schedule assumed. Put the rotation itself on a recurring review, monthly or quarterly, rather than letting it run unexamined until a gap in coverage shows up during a live incident. How fast the rotation gets someone acknowledging and fixing an alert also feeds straight into failed deployment recovery time, so a slipping rotation shows up there before anyone flags it directly.
FAQ
What is an on-call rotation?
A schedule that assigns responsibility for responding to production incidents to a specific engineer or small group for a defined period, with a secondary responder and an escalation policy if the primary doesn't answer in time.
How many engineers do you need for a sustainable on-call rotation?
Datadog recommends 6-8 engineers per rotation so no one is on-call more than about once a month. Xurrent puts the minimum lower, at least 3 to avoid an excessive burden on any one person, with 5 or more recommended for a rotation that doesn't lead to burnout. Below either range, the same few people end up carrying most of the pages.
Does EU working-time law apply to on-call time for a nearshore engineer?
It depends on the country. The CJEU's ruling in Case C-580/19 holds that stand-by time counts as working time under the EU Working Time Directive only when the constraints on the worker's free time are very significant, not automatically for every on-call arrangement. That ruling applies in EU member states. It doesn't automatically extend to a non-EU country like Serbia. Check the specifics with counsel before finalizing a policy that spans more than one country.
Can a contractor or nearshore engineer be part of the on-call rotation?
Yes, and it's common, since the engineer who wrote the code is often the person best placed to respond to it breaking. The part that needs deliberate setup is the contract: who has authority to page them, during what hours, at what response time, and how off-hours response is paid, written down before the rotation goes live rather than assumed.