On-Call Rotation for a Small IT Team: Fair and Sustainable
How a small IT team can cover urgent issues out of hours without burning out — what's worth being paged for, rotation length, handovers, runbooks, compensation, and reviewing every page.
An on-call rotation for a small IT team works when very few things can page anyone, only issues that genuinely can't wait until morning, and a fair rotation covers them: usually a week at a time, with a written handover, a runbook for each alert, a backup person, and compensation. Review every page afterwards and change any alert that didn't need a human right then. Google's SRE guidance, in effect: rare, urgent, actionable pages, or people learn to ignore them.
First decide whether you need on-call at all
Many small internal IT teams don't need formal out-of-hours cover. Ask:
- What breaks outside working hours that can't wait? If the answer is "nothing important", a published "IT hours are 9–6" and a next-morning queue may be enough.
- Who works outside those hours? Shift workers, other timezones, a warehouse, a support team covering weekends.
- What does an hour of downtime cost at 2 am? For a payment system, a lot; for the office printer, nothing.
If only one or two systems truly need cover, cover only those — and consider whether a vendor's support contract should carry that responsibility instead.
What deserves a page
Define the list explicitly and keep it short:
| Page someone | Don't page — next business day |
|---|---|
| Email or sign-in down for everyone | A single user's laptop problem |
| A security incident in progress | A suspicious email already reported |
| A system critical to out-of-hours work is down | Slowness with a workaround |
| Backups failed two nights in a row | One failed backup that will retry |
Everything else goes into the normal queue with a normal deadline. The SLA side of this is in the help desk escalation matrix.
Rotation structure
For a team of three to six:
- One week at a time, handing over on a weekday morning (not Friday evening). Shorter shifts mean more handovers; longer ones are tiring.
- A primary and a backup. If the primary doesn't acknowledge within a set time (say 15 minutes), the page goes to the backup.
- At least three people in the rotation. With two, each person is on call every other week — not sustainable. If you have fewer, reduce what can page, or buy cover.
- Swaps are easy and recorded. Life happens; the schedule should show who's actually on call.
Google's SRE workbook discusses sizing and balancing on-call; the principle scales down: the load on any one person must be sustainable over months, not just survivable for a week.
Handover
A five-minute written handover at each rotation change:
- Anything still open or being watched.
- Changes made this week that could cause trouble.
- Planned work next week (maintenance windows, releases).
- Any alert that was noisy and whether it was fixed.
Put it on a request or in a shared doc, not in someone's head.
Runbooks
Every alert that can page someone needs a runbook: a short page saying what the alert means, how to check whether it's real, the first steps to take, and when to escalate. At 3 am nobody should have to work out from scratch how to restart the mail gateway. Runbooks are knowledge-base articles for the IT team; write them the same way — see how to write knowledge base articles.
During a page
- Acknowledge so the backup isn't paged.
- Assess with the runbook: real or false alarm, how many people affected.
- Communicate if it's real and affects others — a short first notice. See IT outage communication templates.
- Fix or mitigate. Restoring service beats a perfect fix at 3 am; the root cause can wait for daylight.
- Escalate without hesitation if it's beyond the runbook or you're not sure.
- Record what happened on a request, so it can be reviewed.
Review every page
Once a week, look at every page from the past week:
- Was it real? False alarms get fixed or removed.
- Was it urgent? If it could have waited until morning, it shouldn't page.
- Was it actionable? If there was nothing to do, it shouldn't page.
- Is there a root cause to fix? Repeated pages from the same cause become a problem to solve, not a burden to carry — see incident vs service request.
The goal is fewer pages every month. A rotation where people are woken weekly by the same flapping alert will lose people.
A worked example: a four-person team
A company of 120 people with warehouse shifts until 22:00 and a four-person IT team:
- What pages: sign-in down for everyone, the warehouse scanning system down during shifts, a confirmed security incident. Nothing else.
- Rotation: one week each, handover Tuesday 10:00; primary plus backup (the backup is next week's primary, so they're already warming up).
- Covered hours: until 22:00 on weekdays and during weekend shifts; overnight only for security incidents, which go to both people at once.
- Month one: 11 pages. Review showed 6 were a flapping monitor on a printer server — removed. 3 were real scanner outages caused by the same network switch — a problem record, and the switch was replaced. 2 were real sign-in incidents.
- Month three: 2 pages. The rotation is sustainable because the review loop did its job.
The lesson: most of the burden in a young rotation is noise, and noise is fixable within weeks if every page is reviewed.
Fairness and compensation
On-call restricts people's lives even when nothing happens: staying near a laptop, not drinking, not travelling. Recognize it:
- Pay or time off for being on call, plus extra for time actually worked out of hours. Local employment law may set requirements; check it.
- Recovery time after a night's incident — a late start the next day.
- Opt-outs for genuine circumstances, balanced by the team.
- Nobody new on call alone until they've shadowed a rotation.
Tools
You need: a way to page (a phone call or push notification that can wake someone), an escalation to the backup, a schedule people can see, and a record of pages. Many alerting tools do this; for a very small team, even a simple rota and a phone number can work, as long as the list of what can page is short and the backup path is real.
FAQ
Does a small IT team need an on-call rotation?
Only if something important breaks outside working hours and can't wait. Many internal teams can publish support hours and handle issues the next morning; cover only the systems that genuinely need it.
How long should an on-call shift be?
A week is common for small teams, handed over on a weekday morning, with a primary and a backup.
How many people do you need for on-call?
At least three, so nobody is on call more than every third week. With fewer, reduce what can page or arrange external cover.
How do you reduce on-call pages?
Page only for urgent, actionable issues; review every page weekly; fix or remove noisy alerts; and solve the root causes of repeated incidents.
Sources
Building LetRelay, the workspace for research groups and small teams: lab management, supervision tools, and an internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
IT Asset Management for Small Companies: Keep It Light
A practical IT asset management setup for small companies — what to track, one record per asset, lifecycle states from purchase to disposal, linking assets to people and requests, and the security reasons it matters.
IT Outage Communication: Templates for Every Stage
Clear outage messages cut duplicate tickets and frustration. Copy-ready templates for the first notice, updates, resolution and the follow-up review — plus who sends them, where, and how often.
Facilities Request Management: From Broken Chairs to Keys
How to run facilities requests like a proper service — categories, location on every request, safety issues that skip the queue, vendor work, recurring maintenance and the numbers that show where the building needs attention.