Organizing an on-call rotation sounds like a spreadsheet and a duty roster. In reality, it is one of the leadership tasks that show most clearly how seriously a team takes the word “fairness”. Word gets around about who gets called at night, who blocks the weekend and who somehow “can’t right now” every time. The topic keeps me busy because small teams slip into an imbalance here particularly fast.
In this guide you get a six-step process, a handover checklist, metrics for overload and a few rules I consider non-negotiable. It is meant for team leads, engineering managers and anyone who was just asked: “Could you set up on-call for us?”
In short
A fair on-call rotation needs clear rules about which alerts may wake anyone up at all, a fixed rotation with a handover, a second escalation level and compensation nobody has to negotiate. In small teams the frequency is the biggest problem: with four people, everyone is on call for a quarter of the year. That is why reducing the number of night-time alerts pays off more than distributing the roster ever more finely.
What you will learn in this article
- How big a team should be for a sustainable rotation
- Six steps to set up a fair on-call rotation
- A handover checklist for the shift change
- Metrics that reveal overload early
- Typical mistakes that cost trust
What does on-call mean in a software team?
On-call means that a person can be reached outside normal working hours and responds to an incident. They are not at their desk, but they carry the phone, stay within reach of a laptop and skip the second glass of wine. Exactly this invisible part is often underestimated. Even a quiet on-call week is a week in which you are not completely free.
How on-call is treated under employment law and collective agreements depends on contracts, agreements and local rules. So put it on the table from day one, together with HR and, if you have one, the works council. This article is not legal advice. It covers the part you can shape directly as a leader.
How big does a team need to be for a fair on-call rotation?
The Google SRE book names eight people as the minimum for a single-site rotation. With week-long shifts, each person is then on call about one week per month. It also recommends that no more than a quarter of working time goes to on-call. Most teams I know are smaller. Four to six people are the norm in practice.
Do the math for your team honestly. With four people and a weekly rotation, each person is on call 13 weeks a year, more once you factor in vacation and sick days. That is a lot. If you cannot change the team size, you have to turn a different knob.
| Team size | On-call per person (weekly rotation) | What helps |
|---|---|---|
| 3 | every third week, about 17 weeks a year | merge with a neighboring team or limit on-call to weekdays |
| 4–5 | about 10–13 weeks a year | cut night-time alerts radically, define the second level clearly |
| 6–7 | about 7–9 weeks a year | sustainable if the alert load stays low |
| 8+ | about 6 weeks a year or less | the baseline the SRE book names as a minimum |
One lever that is often overlooked: not every service needs round-the-clock coverage. If an internal reporting tool is down for an hour at night, nobody notices the next morning. Clarify with the business which systems really need to wake someone up at night, and write it down.
How to organize an on-call rotation in six steps
Step 1: decide which alerts may wake someone up
The most important step happens before the roster. Only alerts that point to real harm for users and require a concrete action may ring at night. Everything else becomes a ticket for the next working day. A good test for every alert is the question: “What exactly should the person do at three in the morning?” If there is no answer, it is not an on-call alert.
Step 2: choose the rotation and the handover day
Week-long shifts are usually the most practical choice for small teams, because there are fewer handovers. I would not put the switch on a Monday or a Friday. Mondays are busy anyway, and on Fridays nobody wants a handover. Tuesday or Wednesday morning has worked well for me, with a fixed 15-minute handover in the calendar. Swapping is allowed, but it goes into the roster rather than being agreed in a chat.
Step 3: define escalation levels
Nobody should be on their own during on-call. Define at least two levels: the primary person who gets paged first, and a secondary person who takes over if the first does not respond within an agreed time or needs help. Above that sits a third level for major incidents, in small teams usually the team lead. I described the role of the person who coordinates a major incident in the article on the incident commander.
Three escalation levels: primary, secondary and team lead or incident commander for major incidents.
The response time per level should match what you have promised the business or your customers. Write it down together with phone numbers and substitution rules in a place that is reachable at night without a VPN.
Step 4: turn the handover into a ritual
A good handover takes a quarter of an hour and saves hours. I use this checklist as a template:
- Which alerts fired during the last shift, and which of them were real incidents?
- Are there open problems, workarounds or “we are still watching this” topics?
- Which deployments, maintenance windows or campaigns are coming up in the next shift?
- Have runbooks, access rights or contacts changed?
- Do the new person’s phone, alerting app and access work (test alert)?
- Who is secondary, and who is unavailable this week?
Step 5: settle compensation clearly and without haggling
On-call is work, even when nothing happens. The SRE book names time off in lieu or cash as options and recommends a cap relative to salary, so that nobody takes on too many shifts for financial reasons. How exactly you handle it is a matter of contracts and agreements. What matters to me: compensation applies automatically. Nobody should have to ask after a rough night whether they may start later the next morning.
Step 6: review it together every month
Plan 30 minutes once a month to look at the numbers and the experiences. Which alerts were unnecessary? Which incidents happened again? Who carried a particularly heavy load? Every review should produce at least one concrete task, for example switching off an alert or extending a runbook. Larger incidents get their own blameless postmortem.
How to spot on-call overload
Feelings matter, numbers help when you argue. The SRE book assumes that an incident including follow-up work costs about six hours on average. From that it derives a maximum of two incidents per twelve-hour shift. The median should be zero incidents per day. These values translate well to a small team:
| Metric | Healthy | Warning sign |
|---|---|---|
| Incidents per shift (12 h) | mostly 0 | regularly 2 or more |
| Night-time alerts per week | 0–1 | several, especially recurring ones |
| Share of alerts without required action | close to 0 | one in five or more |
| Swapped or cancelled shifts | rare | frequent, always the same people |
Watch out for soft signals as well. When people look exhausted after an on-call week, plan vacations around the rotation or stop pushing back, that is a warning, even if the numbers still look fine.
Typical on-call mistakes
- The most experienced people are always secondary: the night-time calls still end up with them, just without compensation.
- The team lead opts out: whoever plans the rotation should know it first-hand. At least as the second or third level, the manager belongs in it.
- Heroics get rewarded: whoever saves everything alone at night gets praise, whoever escalates early gets a frown. That trains the team to grit their teeth instead of asking for help.
- New people without guidance: the first one or two shifts work better while “shadowing” an experienced colleague.
- Alerts never get cleaned up: without a monthly review the list keeps growing and on-call gets louder every week.
My take
I consider on-call a yardstick for leadership. The roster itself is quickly done. The harder part is keeping it fair when things get uncomfortable: when a colleague goes on parental leave, when someone cannot do night shifts for health reasons, when a release goes wrong. Those moments decide whether the team trusts the process.
My principle: the best on-call rotation is the one that is rarely needed. Every hour you put into better alerts, a more robust architecture and clear runbooks pays off twice, in fewer interrupted nights and in more trust. If you only optimize the roster, you merely spread the load more evenly instead of making it smaller.
One more thing: talk openly about the fact that on-call is a burden. Admitting that a week was exhausting should not get anyone labelled as “not resilient”. People first means, very concretely here, that the team’s health comes before perfect coverage.
FAQ
How long should an on-call shift be?
In small teams, week-long shifts are the most common, because there are fewer handovers. With a high alert load, shorter shifts or separating weekdays from weekends take more pressure off.
Does the team lead have to be on call too?
Not necessarily as the primary person, but at least as an escalation level. Whoever feels the load first-hand makes better decisions about alerts, priorities and compensation.
What if the team is too small for a rotation?
Check whether all services really need night-time coverage, merge on-call with a neighboring team or limit it to weekdays. At the same time, the number of night-time alerts should go down.
How many alerts per shift are too many?
As a rule of thumb, the Google SRE book names at most two incidents per twelve-hour shift, with a median of zero per day. If you are regularly above that, it is a task for the whole team.
To keep on-call from breaking down under false alarms, it pays to look at the alarms themselves. I show how to build them so that only real problems page anyone in Avoid alert fatigue: alarms worth waking up for.
Your next step
Take the alerts of the last four weeks and mark every one that fired outside working hours. Ask for each: did someone really have to act right away? This single list is already a good starting point for the next team conversation.
How do you organize on-call, and what made the biggest difference for fairness in your team? I look forward to your comment.
Sources
This post was created with AI assistance.
👉 Next step: Not sure which AWS service fits your use case? My AWS service finder asks a few questions and points you to the right one.
📬 Stay updated: New articles on serverless, AI and leading tech teams via RSS, browser push or the weekly newsletter (in German).
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)