Equal rotation does not mean fair rotation.
A quiet Sunday afternoon shift is not the same as a P1-heavy Friday night. But most on-call schedules treat them identically: same hours, same rotation, same compensation. Round-robin looks balanced on a spreadsheet. It is not balanced in reality. Some engineers consistently draw the hard shifts — the noisy services, the overnight pages, the holiday weekends — while others coast through quiet rotations without a single alert.
The result is predictable: burnout, resentment, and attrition. And most managers never see it coming because the schedule looks "fair" on paper. This guide introduces a practical framework — Difficulty-Weighted Hours— to measure the actual burden of on-call work, identify hidden inequities, and fix them before your best engineers quit.
2.3x
more likely to burn out when treated unfairly at work
Gallup Workplace Report
42%
of engineers cite on-call burden as primary reason for leaving
Industry survey, 2024
30%
increase in operational toil in 2025 — despite AI adoption
RunFrame State of Incident Management, 2026
The hidden inequities in "fair" schedules
Round-robin rotation is the default for most teams. Everyone takes the same number of shifts. Everyone covers the same number of hours. On paper, it is perfectly equitable. In practice, it hides at least five systemic sources of unfairness.
1. Service noise
Not all services page equally. One engineer covers a mature, well-instrumented API that fires an alert once a quarter. Another covers a legacy billing system that generates ten pages per shift. Same rotation, radically different experience. The engineer on the noisy service loses sleep, burns cognitive energy, and accumulates fatigue — all while the schedule says they had the same workload as everyone else.
2. Time-of-day bias
A weekday shift during business hours is fundamentally easier than a Friday-night or Saturday-overnight shift. During business hours, other engineers are around to help, stakeholders are reachable, and the engineer can handle pages without disrupting their personal life. Night and weekend shifts carry a higher cognitive and personal cost per hour — but most schedules weight every hour the same.
3. Holiday clustering
Whoever draws on-call over Christmas, New Year's Eve, or a long weekend absorbs a disproportionate burden that a single round-robin cycle cannot correct. You cannot "make up" a ruined holiday by giving someone a quiet Tuesday shift next month. The personal cost is not symmetrical.
4. Incident severity luck
One engineer gets three P1 incidents in a month. Another gets zero. Both were on-call for the same number of hours. The schedule was "fair," but the experience was not even close. Severity luck compounds over time — the same unlucky engineer often ends up with the reputation of being "always in incidents," which leads to more escalations directed their way.
5. Seniority drift
Senior engineers get pulled into escalations whether or not they are officially on-call. A P1 hits at 2 AM and the on-call engineer pages the senior for help. This creates an invisible additional burden that never appears in rotation metrics. Over time, your most experienced people burn out fastest — not because they are on-call more often, but because they are effectively on-call all the time.
Why you can't fix what you don't measure
Most teams track three things about on-call: who was on-call, how many hours they served, and how many alerts they received. These metrics are easy to collect and easy to report. They are also insufficient.
Alert count is a proxy, not a measure of burden. A single P1 incident that takes four hours of active troubleshooting, cross-team coordination, and a 3 AM war room is objectively harder than ten P4 alerts that auto-resolve. But if you are counting alerts, the engineer with ten P4s looks busier. If you are counting hours, both engineers look identical.
What you actually need is a metric that captures the subjective difficultyof the shift — how hard it actually was for the person who worked it. Without that signal, you are flying blind. You will continue to rotate engineers through "equal" shifts that are anything but, and you will not understand why your best people are burning out despite a schedule that looks perfectly balanced.
The good news: capturing this signal is surprisingly simple. It takes five seconds per shift and creates a dataset that transforms how you manage on-call fairness.
Introducing Difficulty-Weighted Hours
Difficulty-Weighted Hours is a framework for measuring the actual burden of on-call work, not just the time spent. The concept builds on On-Call Difficulty Ratings— a simple 1–5 score captured at the end of every shift. That rating is multiplied by the shift duration to produce a single, comparable number.
The difficulty scale
| Rating | Description |
|---|---|
| 1 | Quiet, no incidents |
| 2 | Light — minor issues handled easily |
| 3 | Moderate — required focused attention |
| 4 | Heavy — multiple incidents or complex troubleshooting |
| 5 | Critical — P1 incident, sleep disrupted, high stress |
The formula
Difficulty-Weighted Hours = Shift Hours × Difficulty Rating
A 12-hour shift rated at difficulty 1 produces 12 Difficulty-Weighted Hours. The same 12-hour shift rated at difficulty 5 produces 60. This single number captures what raw hours and alert counts miss: how hard the shift actually was.
Why this works: a real example
| Engineer | Shifts | Total Hours | Avg Difficulty | Difficulty-Weighted Hours |
|---|---|---|---|---|
| Alex | 4 | 48 | 2.0 | 96 |
| Jordan | 4 | 48 | 4.25 | 204 |
| Sam | 4 | 48 | 1.5 | 72 |
Same hours. Same number of shifts. Wildly different burden. Jordan is doing 2x the work Alex is — and nearly 3x what Sam is. Without difficulty weighting, all three engineers look identical in your scheduling tool. With it, the inequity is impossible to miss.
This is not a theoretical exercise. If you ran this analysis on your team right now, you would almost certainly find that one or two engineers are carrying a disproportionate share of the on-call burden. The question is whether you want to see that data or continue pretending the schedule is fair.
Four actions to fix on-call fairness
Measuring difficulty is the foundation. But measurement alone does not fix the problem. Here are four concrete actions that turn data into equitable outcomes.
1. Track difficulty ratings at every shift sign-off
Make the difficulty rating a required field at shift sign-off, not an optional survey. It takes five seconds to complete. It should be as non-negotiable as closing out your incident tickets. The key is consistency: if you only capture ratings when someone remembers to ask, the data is useless. Build it into your sign-off workflow so it happens automatically, every time.
Resist the temptation to over-engineer the rating. A simple 1–5 scale is sufficient. Engineers will calibrate naturally over a few cycles. You do not need a rubric — the descriptions above are enough to anchor the scale.
2. Review difficulty-weighted burden monthly
Once you have the data, look at it. Pull the difficulty-weighted hours for every engineer on the team and compare them. If one person is consistently 2–3x the team average, that is a problem you need to address — not next quarter, not at the next performance review, but in the next scheduling cycle.
Monthly is the right cadence for most teams. Weekly is too noisy (a single bad shift skews the numbers). Quarterly is too slow (by the time you notice the problem, the engineer is already interviewing elsewhere).
3. Rotate high-burden services
Do not let the same person cover the noisy service every cycle. If your billing system pages ten times more than your API gateway, rotate service responsibility alongside time slots. This is the single most impactful change most teams can make, and the one they most often overlook.
The common objection is domain expertise: "Only Sarah knows the billing system well enough to be on-call for it." This is a training problem, not a scheduling constraint. If only one person can handle a service, you have a bus-factor problem anyway. Cross-training your team on high-burden services solves both fairness and resilience.
4. Tie compensation or time-off to actual burden
If one engineer's difficulty-weighted hours are double the team average, they should get comp time or additional compensation. Equal pay for unequal burden is a retention risk. The specifics depend on your company — some teams offer a floating day off, others pay a per-incident bonus, others let engineers "bank" difficulty points toward schedule priority.
Whatever mechanism you choose, make it explicit and transparent. The worst outcome is when managers quietly give comp time to the engineers who complain loudest. That rewards squeaky wheels, not actual burden. Use the data.
What fair on-call looks like in practice
Fair on-call is not a one-time fix. It is a recurring conversation. The best teams hold a short monthly fairness review — 15 minutes at the end of a retro or team meeting — using a simple five-point agenda.
Monthly fairness review checklist
- Review difficulty-weighted hours per engineer for the past month
- Identify any engineer more than 50% above the team average
- Check night and weekend shift distribution for the past quarter
- Ask openly: "Did anyone get hit with something unusually hard this month?"
- Adjust next month's schedule to rebalance identified inequities
One additional practice worth adopting: publish the difficulty-weighted leaderboard (anonymized or not, depending on team culture) so everyone can see the distribution. When the data is visible, fairness conversations become about numbers, not feelings. Engineers who thought they were carrying more than their share might discover they are average. Engineers who never complained might turn out to be significantly overburdened. Either way, the data replaces guesswork.
The MSP angle — why fairness matters even more for service teams
Everything above applies to internal engineering teams. For Managed Service Providers (MSPs), the fairness problem is amplified by a factor that internal teams do not have: client-specific complexity.
An engineer covering quiet Client A — modern infrastructure, clean documentation, responsive stakeholders — has a fundamentally different shift than one covering Client B with legacy on-prem servers, undocumented network topology, and a habit of making changes without telling anyone. Same hours, same rotation, vastly different burden.
MSPs also face a compounding problem: the best engineers tend to get assigned to the hardest clients because they are the only ones who can handle the complexity. This creates a vicious cycle where your top performers absorb the most burden, burn out fastest, and leave — taking irreplaceable client knowledge with them.
Difficulty-weighted tracking is particularly valuable here because it makes the client-burden disparity visible. When your data shows that shifts covering Client B consistently rate 4–5 while Client A shifts rate 1–2, you have the evidence you need to either rebalance assignments, invest in improving Client B's environment, or adjust pricing to reflect the operational cost of supporting that client.
If you run an MSP and you are not tracking on-call difficulty per client, you are making staffing and pricing decisions based on incomplete information. Your fairness problem is also a margin problem.
Measure what matters — not just who was on-call, but how hard it was
Shiftctl captures difficulty ratings at every shift sign-off, surfaces burden distribution across your team, and gives you the data to build genuinely fair rotations. Free for 2 users. No credit card required.
Frequently asked questions
How do you measure on-call fairness?
Start by tracking three metrics per engineer: total on-call hours, number of alerts received, and a self-reported difficulty rating (1–5) at every shift sign-off. Multiply hours by difficulty to get Difficulty-Weighted Hours, then compare the distribution across your team monthly. If any engineer is consistently more than 50% above the team average, your rotation has a fairness problem.
What is difficulty-weighted on-call scheduling?
Difficulty-weighted scheduling is an approach where future schedule assignments factor in past burden, not just time served. Engineers who had harder shifts (higher difficulty-weighted hours) get lighter assignments in subsequent cycles. This ensures the cumulative burden stays balanced over time, even when individual shifts vary in intensity.
How do you prevent on-call burnout?
Three mechanisms: limit consecutive on-call shifts (no more than one week in a row), ensure adequate rest periods between rotations (minimum 48 hours off after a night shift), and track difficulty-weighted hours to identify and rebalance chronic overburdening before it leads to burnout. The single biggest predictor of on-call burnout is not total hours — it is the perception that the burden is unfair.
Should on-call engineers be compensated for harder shifts?
Yes. Equal compensation for unequal burden is a retention risk. The specific mechanism varies — comp time, per-incident bonuses, difficulty-weighted schedule priority — but the principle is the same: harder shifts should be acknowledged and compensated proportionally. Use difficulty-weighted hours as the basis, not subjective judgment.
What is a fair on-call rotation?
A fair rotation is one where the cumulative difficulty-weighted burden is roughly equal across all engineers over a rolling period (typically a quarter). This is different from an equal rotation, where only hours and shift counts are balanced. Fair rotations account for service noise, time-of-day, incident severity, and holiday coverage.
How often should you review on-call fairness?
Monthly is the right cadence for most teams. Weekly reviews are too noisy — a single bad shift distorts the picture. Quarterly reviews are too slow — by the time you spot a chronic imbalance, the affected engineer may already be disengaged. Use a monthly 15-minute review with the five-point checklist described above.
Can you automate on-call fairness tracking?
Yes. Tools like Shiftctl capture difficulty ratings as part of the shift sign-off workflow, automatically calculate difficulty-weighted hours, and surface burden distribution across your team. This eliminates the manual spreadsheet work and ensures ratings are captured consistently at every shift change.