“Everyone does one week per month” is not a fair rotation. It’s a spreadsheet.
Every engineering manager has run the same audit. Open the rotation tool. Count who was on-call last quarter. Confirm the hours are close enough across the team. Close the tab. The rotation looks fair but it isn’t. This on-call rotation fairness calculator shows you what the schedule hides.
Then one of the “fair” engineers puts in notice.
The problem isn’t that managers are careless. It’s that the tools measure the wrong thing. On-call cost is not hours on the schedule. It’s a 2 a.m. alert on Saturday for a P1 the engineer couldn’t hand off. Two engineers who each did seven days of on-call last month can have a 5x gap in the actual burden they absorbed. The schedule doesn’t show that gap. This framework does.
Below is a working calculator any engineering manager can run in a spreadsheet using data most on-call tools already export. No new tooling required.
Why “rotation coverage” is not “rotation fairness”
Fairness in on-call has three dimensions most rotations collapse into one.
Frequency: how often an engineer is alerted. This is the only dimension most rotations track.
Timing: when the alerts land. An alert at 10 a.m. Tuesday and an alert at 3 a.m. Saturday are not equivalent events, even though they show up as one row each in the log.
Severity and resolution cost: a P1 that took 90 minutes of active response is nothing like a false-positive alert that was cleared in 30 seconds. Both count as one alert.
A rotation that equalizes frequency but ignores timing and severity is pushing the real cost onto whoever happens to draw the unlucky weeks. Over six months, that engineer is quietly carrying 2x to 4x the actual burden while the schedule says they are square. That is exactly the gap this on-call rotation fairness calculator is designed to surface.
The Fair Alert Score (FAS)
The Fair Alert Score is the core metric this on-call rotation fairness calculator is built around a single number per engineer per month that captures all three dimensions. The formula is deliberately simple so it runs in Google Sheets.
For every alert an engineer received in the last 30 days, compute:
Alert Burden = Time Weight × Day Weight × Severity WeightTime Weight (based on engineer’s local time)
| Window | Weight |
|---|---|
| 22:00 to 06:00 | 3.0 |
| 18:00 to 22:00 | 1.5 |
| 06:00 to 18:00 | 1.0 |
Day Weight
| Day type | Weight |
|---|---|
| Public holiday | 3.0 |
| Saturday or Sunday | 2.0 |
| Weekday | 1.0 |
Severity Weight
| Severity | Weight |
|---|---|
| P1 / SEV-1 | 3.0 |
| P2 / SEV-2 | 1.5 |
| P3 or lower | 1.0 |
| False positive / auto-resolved / no human action | 0.5 |
Monthly Fair Alert Score
Sum every Alert Burden value for the engineer over 30 days.
FAS = Σ (Time Weight × Day Weight × Severity Weight)An engineer who received five P2 alerts during business hours on weekdays has a FAS of 5 × 1.0 × 1.0 × 1.5 = 7.5. An engineer who received one P1 at 3 a.m. on a Saturday has a FAS of 1 × 3.0 × 2.0 × 3.0 = 18.0. Same frequency-normalized count. Very different lived experience.
This number is not a utilization target. It is a distribution signal.
The Fairness Distribution Check
Once you run the on-call rotation fairness calculator and every engineer has a monthly FAS, compute three values across the team.
Team median FAS: the middle of the distribution, not the average. Averages hide the outliers you are trying to find.
Top-to-median ratio: the highest FAS divided by the median. A healthy rotation keeps this under 1.8. A ratio between 1.8 and 2.5 is a yellow flag. Above 2.5 is a red flag: one engineer is carrying a burden so far above the team baseline that the schedule is not functioning as a rotation.
Bottom-to-median ratio: the lowest FAS divided by the median. Below 0.5 is also a yellow flag. An engineer who is significantly under-pulled is often being quietly protected, which means someone else is compensating.
Decision table
| Top-to-median ratio | Reading | Action |
|---|---|---|
| Under 1.3 | Distribution is tight | No action |
| 1.3 to 1.8 | Normal variance | Monitor trend |
| 1.8 to 2.5 | Unfair concentration forming | Rebalance within 30 days |
| Over 2.5 | Retention risk | Rebalance within 7 days, check in with the engineer |
Three anchor metrics that FAS does not catch
The on-call rotation fairness calculator captures total burden through FAS, but three patterns still drive attrition faster than raw burden.
1. Weekend anchors
A weekend anchor is any alert on Saturday or Sunday that triggered more than 30 minutes of active response. Count these per engineer in a rolling 90-day window.
If the team median is one weekend anchor per quarter and an engineer has three, their calendar has been repeatedly ruined even if their FAS looks normal. Cancelled weekends are what engineers remember, and what they tell recruiters about.
2. Consecutive-week load
Back-to-back on-call weeks are qualitatively different from the same number of weeks spread across a quarter. Count the longest consecutive-week stretch per engineer. Anything beyond two consecutive weeks in a 90-day window should require a manager conversation and explicit buy-in from the engineer.
3. Recovery debt
Recovery debt is the operational equivalent of sleep debt. The rule is simple.
- Every alert between 22:00 and 06:00 earns the engineer one recovery day.
- Every weekend anchor earns two recovery days.
- A recovery day must be taken within 14 days of the event to clear the debt.
- Unused recovery days accumulate.
An engineer carrying 5 or more unpaid recovery days at the end of a quarter is a retention risk regardless of their FAS. The burden was real. The organization just never paid it back.
Three roles, three ways to run the calculator
Role 1: The engineering manager running a quarterly rotation review
Input: the last 90 days of alerts exported from your on-call tool, with timestamp, engineer, and severity.
What you compute:
- Monthly FAS per engineer for each of the three months
- Top-to-median ratio per month
- Weekend anchor count per engineer in the 90 days
- Consecutive-week stretches per engineer
- Unpaid recovery days per engineer
What you look for: any engineer who is red-flagged on two or more of these metrics. That is not a bad month. That is a pattern the schedule is producing, and the schedule will keep producing it unless you change the rotation design.
What you do: rebalance the next rotation to give the flagged engineer a protected stretch (typically 30 to 45 days without primary coverage), and schedule a direct conversation with them about whether they want to stay on the primary rotation at all.
Role 2: The staff engineer auditing their own burden
Input: your own alert history for the last 90 days.
What you compute: your personal FAS trend month over month. Your own weekend anchor count. Your own recovery debt.
What you look for: a rising FAS trend when the rotation size has not changed, which means the unfair share is landing on you specifically. A weekend anchor count of three or more in a quarter. Recovery debt that is not clearing.
What you do: take this into your next 1:1 with your manager. Ask for the team’s median FAS. If your ratio is above 1.8, the conversation is no longer about your workload. It is about the rotation design.
Role 3: The CTO reviewing retention risk
Input: monthly Top-to-median FAS ratio across every on-call rotation in the organization.
What you compute: which rotations are consistently running with a ratio above 1.8. Which engineers are consistently in the top quartile of their rotation’s FAS for two or more consecutive quarters.
What you look for: the overlap between “top quartile FAS for two quarters” and “staff plus level engineers”. This overlap is your retention risk list. It is almost never the list your HR system would produce.
What you do: pull the on-call data into the same meeting where you review attrition, compensation bands, and promotion slates. Treat it as a first-class signal, not an operations footnote.
Running the on-call rotation fairness calculator this quarter
A rough implementation plan that fits in two engineering weeks.
- Export the last 90 days of alert data from your current on-call system. At minimum you need: timestamp in engineer’s local time, engineer ID, severity, and whether the alert was resolved by a human action.
- Build a spreadsheet with one row per alert and columns for the three weights. Compute Alert Burden per row.
- Pivot by engineer and month to get FAS.
- Compute the median, the top-to-median ratio, and the bottom-to-median ratio per month.
- Build a second sheet for weekend anchors, consecutive-week stretches, and recovery debt.
- Share the numbers with the affected engineers before you share them with anyone above you. The data is personal. It belongs to them first.
- Put a recurring 45-minute item in your quarterly manager cadence to re-run this review.
What the calculator is not
The on-call rotation fairness calculator is a diagnostic, not a performance metric. It tells you which engineers are absorbing disproportionate burden. It does not tell you whether any individual engineer is performing well or badly. Using FAS as a performance signal or tying it to compensation reviews will destroy its value within one quarter, because engineers will quietly swap or decline alerts to manage their number.
The calculator is also not a replacement for asking. Every metric in this framework is a prompt to have a specific conversation with a specific engineer. The numbers surface the pattern. The engineer explains the cost.
The quiet advantage of measuring this
Most engineering organizations cannot tell you which of their engineers is carrying the unfair share of on-call burden right now. They can tell you who is on the schedule this week. Those are not the same question.
The managers who answer the first question accurately will keep their senior engineers longer than the managers who only answer the second. The rotation will not look different on paper. The retention numbers will.
On-call fairness is a measurable property. This on-call rotation fairness calculator gives you the framework to measure it.
Make fairness measurable in your next rotation
ITOC360 captures the timestamp, severity, resolution, and engineer data that makes the on-call rotation fairness calculator possible. Book a walkthrough and we will run your first review together.
Sources and further reading
- State of Incident Management 2026, Runframe
- Engineering Leadership Report 2025, LeadDev
- SRE Book: Being On-Call, Google
- On-Call Burnout: What Incident Data Doesn’t Show, DEV Community, 2025