MSP On-Call Rotations: Why They Break Down and What to Replace Them With

Key takeaways

• An on-call rotation spreads after-hours duty across a team on a fixed schedule. At MSPs, it tends to break down when alert volume grows faster than the bench.
• A fair rotation needs a written policy that includes what counts as an emergency, how on-call is paid, the recovery time after rough nights, and a clean handoff.
• Many MSPs move to a layered night model: automation for routine requests, live technicians overnight, and on-call kept for true P1s.

On paper, an on-call rotation is about as fair as scheduling gets. Five techs take turns covering after-hours, one week each. But equal weeks don't necessarily mean equal work. One tech might get called three times during their week, while the next gets called thirty times.

That gap is where most MSP on-call rotations start to wobble. This guide covers the mechanics first: common on-call rotation schedules, a sample template, on-call pay models, and what belongs in an on-call policy. Then we look at why rotations break down as an MSP grows, and the night model many MSPs move to instead.

LTVplus offers Managed Technical Support for MSPs, including overnight coverage. If you're comparing broader coverage options, our guide to MSP after-hours support walks through them. For the human side, see how to reduce MSP technician burnout.

What is an on-call rotation?

An on-call rotation is a schedule that shares after-hours duty across a team. Each person takes a turn, often a week at a time, as the first contact for urgent alerts outside business hours. Most rotations also name a backup and a senior escalation contact.

At most MSPs, that looks like three roles:

1. Primary on-call: responds to every urgent alert or call during their shift and decides what can wait until morning.
2. Secondary on-call: backs up the primary. Some teams only call on the secondary when the primary misses an alert. Others hand the secondary the non-urgent work so the primary can focus on urgent issues, a split Google describes in its Site Reliability Engineering book.
3. Escalation contact: usually a senior engineer or the service manager, called for outages, security incidents, or anything outside the primary's depth.

What does a typical on-call rotation schedule look like?

There's no single right on-call schedule because the best fit depends mostly on your headcount and how busy your nights are. Here are the five models MSPs use most.

Model	How it works	When it works	Watch out for
Weekly single on-call	One person covers all after-hours for a week	Low alert volume, 5+ techs	No backup if that person misses an alert
Primary / secondary	A backup covers if the primary misses an alert or gets overloaded	Moderate volume	The secondary gets pulled in so often it becomes a second primary
Follow-the-sun	Teams in other time zones cover their own daytime	Teams in two or more regions	Handoffs across regions; not an option for a single-location MSP
Split nights	Early and late halves of the night go to different people	Larger teams	The midnight handoff gets skipped
Live overnight + on-call escalation	Live technicians work the night; on-call only for P1s	Any size, in-house or with a partner	Fuzzy escalation criteria send everything to on-call anyway

Sample on-call rotation schedule template (5-person team)

Here's what a simple primary/secondary on-call calendar can look like for a five-person team. It's illustrative, so swap in your own names, shift lengths, and escalation contacts.

Week	Primary	Secondary	Escalation
Week 1	Tech A	Tech B	Senior engineer
Week 2	Tech C	Tech D	Senior engineer
Week 3	Tech E	Tech A	Senior engineer
Week 4	Tech B	Tech C	Senior engineer

With five people filling two slots a week, most techs end up on call, as primary or secondary, more than one week in four. That detail matters later.

Publish the calendar where your team already works, like your PSA, and put the escalation contact's number right on it. Nobody should be searching for a phone number while a client's server is down.

Try this: Run the schedule forward 12 weeks before you publish it. Holidays, planned leave, and new hires shift the pattern more than you'd expect, and it's easier to fix gaps on paper than at 9 p.m. on a Friday.

What on-call rotation software do MSPs use?

You likely own most of the pieces already. On-call rotation software for MSPs usually comes from three places:

1. Your PSA. ConnectWise PSA, Datto Autotask, HaloPSA, and Syncro can all route after-hours tickets based on who's on duty.
2. Your RMM and monitoring tools. NinjaOne, N-able, Atera, Auvik, and PRTG generate the alerts, and their alert policies decide what wakes someone up at night and what waits in a queue.
3. A dedicated on-call alerting tool. This sits between monitoring and your techs' phones, escalates if an alert goes unanswered, and logs who acknowledged what.

Keep your runbooks in your documentation platform, such as IT Glue, so whoever is on call can find client details fast.

A word of caution: If you still route on-call alerts through Opsgenie, plan a move. Atlassian stopped selling it on June 4, 2025, and support ends April 5, 2027.

How MSPs should handle on-call pay

Most MSPs pay for on-call with one of these models or a combination:

• Flat stipend per shift or a set amount for each on-call week or night. This is predictable for both sides so it's easy to budget. The catch is that a quiet week and a brutal week pay the same.
• Per-incident pay. Techs earn a set amount for each call-out. This system tracks actual work, but it can make noisy alerts feel like a perk instead of a problem to fix.
• Hourly pay for time worked. Techs log the time they spend on after-hours incidents. It's the fairest for active hours and depends on clean time tracking in your PSA.
• Time off in lieu. This refers to time off in exchange for on-call duty or rough nights. It protects recovery, but it's hard to honor when the bench is already thin. In the U.S., this can't replace overtime pay owed to non-exempt employees, so treat it as a bonus on top of required pay.
• A mix. Many MSPs pair a base stipend with per-incident or hourly pay. If you go this route, keep it simple enough to explain in one sentence.

Pay design can also double as a workload control. Google's SRE book notes that the company compensates on-call with either time off in lieu or cash, capped at a share of salary, and that the cap limits how much on-call any one person takes on.

For an MSP, that's a useful idea to borrow: a ceiling on on-call compensation also nudges you to spread the load.

Is on-call time paid under U.S. law?

It depends how restricted the employee is. Under the U.S. Department of Labor's Fact Sheet #22, an employee who has to stay on call at the employer's premises is working during that time. An employee who can stay home, or leave word of where they can be reached, is generally not working while on call. Tighter conditions in their free time can change that.

Rules differ by country and state, and contractors follow different rules than employees. Treat this as a starting point, not legal advice. Do check with local counsel before you finalize your on-call pay policy.

What should an MSP on-call policy include?

A written on-call policy settles most arguments before they start. At minimum, cover these seven points:

1. Emergency criteria. What's urgent enough to wake someone up, by client tier and priority, and what waits until morning.
2. Response expectations. How fast the on-call tech should acknowledge an alert and start working it.
3. Escalation path. Who's next if the primary can't resolve the issue, and how long to try before escalating.
4. Pay and comp rules. Which model you use, and how incidents and time are logged.
5. Recovery time. What happens the morning after a heavy night, such as a late start or a lighter queue.
6. Swap and coverage rules. How trades work, and who covers sick days and holidays.
7. Handoff notes. What gets written down at each shift change (more on this below).

Our MSP after-hours support guide includes a full on-call policy example if you want a model to adapt.

Why do on-call rotations break down at MSPs?

Even a well-run rotation has limits, and MSPs tend to hit them early. Here's where the strain usually comes from.

The bench is smaller than the math needs

• Remember the five-person template? Google's SRE team caps on-call at 25% of an engineer's time. By that rule, it works out that a single-site team running 24/7 primary and secondary on-call needs at least eight engineers, so each person is on-call about one week a month.
• Plenty of MSPs run their night rotation with half that, which means every tech carries more nights than a sustainable schedule allows.

Alerts scale with clients, not headcount

• Every new client adds servers, endpoints, and documentation to the same rotation.
• At night, the on-call tech jumps between a dozen client environments, often with less context than the daytime tech who owns each account.

A shift can only absorb so many incidents

• Google estimates a single on-call incident takes about six hours once you count the fix, the root-cause work, and the write-up.
• That caps a 12-hour shift at two incidents. Beyond that, follow-up slips into the next day, and the ticket backlog follows the tech into their regular hours.

Pay stops matching the work

When nights get busier and compensation stays flat, techs rarely raise it directly. You see it first in swap requests and slower acknowledgments, and sometimes later in a resignation letter.

Knowledge sits with one or two people

For certain clients, the real escalation path is to call the person who built that network. Sure, the calendar says the load is shared, but the hard calls keep landing on the same person.

The wider IT workforce is already stretched. In a March 2025 survey, ISACA found that 73% of European IT professionals had experienced work-related stress or burnout, and 61% attributed their work stress to heavy workloads. An overloaded rotation pushes that workload into people's evenings.

Keep on-call for real emergencies

LTVplus provides dedicated technicians who work your overnight tickets and alerts inside your PSA and RMM, following your escalation paths and SOPs.

Your on-call engineer gets called only for real incidents, with the diagnostics already attached. Start with a 3-month pilot, with no long-term commitment. Book your free consultation here.

What can MSPs replace on-call rotations with?

The fix that holds up best is a layered night model. Instead of sending every after-hours alert to just one tech's phone, you sort the night's work by who, or what, should handle it.

Layer	What it handles	Examples
1. Automation and Tier 0	Routine, repeatable requests	Password resets, self-service fixes, auto-remediation scripts, AI-assisted triage and ticket routing
2. Live overnight technicians	Tier 1 and Tier 2 tickets that need a person	Email and access issues, printer problems, first-pass alert triage
3. On-call engineer	True P1s and Tier 3	Outages, security incidents, anything your escalation criteria flag

Layer 1 takes volume off the table. Automation and self-service handle routine requests, like password resets, without a tech. AI-assisted triage also bundles related alerts together, so one problem sends one alert instead of a dozen. Google's SRE book recommends getting close to a 1:1 ratio of alerts to incidents for exactly this reason. Our guide to Tier 0 IT support covers where to start.

Layer 2 is people who work the night instead of sleeping next to the phone. You can staff it a few ways:

• An in-house night shift. Full control, though you need enough headcount to cover nights, weekends, leave, and turnover.
• Staff augmentation. You add technicians who work under your direction. It's a solid route if you already have the processes and management capacity to run a night team. Our comparison of staff augmentation vs. managed services breaks down when each fits.
• A managed partner. A partner provides, trains, and manages the overnight team, which works inside your tools and processes. This can cover help desk tickets, NOC alert triage, or both.

If you're weighing what overnight coverage means for your client contracts, see how to offer a 24/7 SLA without staffing it yourself.

Layer 3 is your on-call engineer, now called only for P1s and Tier 3 work.

How do you hand off between night coverage and on-call?

The layered model only works if information moves cleanly between layers. A few on-call best practices keep handoffs tight:

• Write shift notes in the PSA ticket, not in chat. The next person should see the full history in one place.
• Share an open-incident list at every handoff. Include what's in progress, what's waiting on a client, and what was escalated.
• Hold a short morning review. Look at what reached on-call overnight and whether it needed to.
• Revisit escalation criteria monthly. If the same issue keeps waking someone up, fix the criteria or the root cause.

For how tickets should move from Tier 1 to Tier 3, see our guide to MSP escalation workflows.

Should MSPs get rid of on-call entirely?

No, and most MSPs shouldn't try. Outages and security incidents will always need someone senior who can make the call.

If you're not sure where to go, look back at last month's after-hours calls and check what each one actually needed.

• Mostly simple fixes, like password resets or single-user issues. Your on-call techs are getting woken up for work a Tier 1 tech could handle with a runbook. A new schedule would only move those calls to someone else, so live overnight coverage is the better fix.
• Mostly real emergencies, like outages or security incidents. On-call is doing its job. Keep the rotation, and use the policy section above to make it fairer.

LTVplus is the managed technical support partner MSPs trust to handle their most important clients. We offer 24/7 support coverage across chat, email, social, and voice, with dedicated technicians who work inside your PSA and follow your SOPs. Think of us as a flexible extension of your team.

Book a free consultation to talk through your overnight coverage.

Frequently asked questions

What is an on-call rotation in an MSP?

An on-call rotation is a schedule that assigns technicians to handle urgent IT issues outside regular business hours. Most MSP rotations include a primary technician, a backup, and a senior escalation contact for incidents that require additional expertise.

Is on-call the same as working a night shift?

No. An on-call tech is off duty but reachable, and only works when called. A night-shift tech is actively working tickets and alerts for the whole shift. That difference affects pay, recovery time, and in the U.S., whether the hours count as time worked.

What counts as an on-call emergency at an MSP?

Anything that stops a client's business or puts their data at risk, such as a full outage or an active security incident. Single-user issues usually wait for the morning queue. Our after-hours support guide has a sample P1 to P4 breakdown you can adapt.

How many technicians do you need for a 24/7 on-call rotation?

The number depends on the coverage requirements and workload. As a general planning benchmark, a team needs at least eight engineers to maintain a 24/7 primary and secondary on-call rotation while keeping each person's on-call commitment near one week per month. Smaller teams may need additional coverage support to avoid overloading technicians.

What should an MSP on-call policy include?

A written policy should define emergency criteria, response expectations, escalation procedures, compensation, recovery time, shift swaps, holiday coverage, and handoff requirements. Clear rules help technicians understand their responsibilities and prevent routine issues from unnecessarily waking senior engineers.

Can an MSP eliminate its on-call rotation?

Most MSPs still need an escalation path for critical outages, security incidents, and other high-priority issues. However, they can reduce the burden on their engineers by combining automation, live overnight technical support, and on-call escalation for genuine emergencies.