Someone has to be on call when your site goes down at 2 AM. If you don't have a clear on-call schedule, the same people get paged every time, burnout follows, and incidents get missed.
A rotation that everyone understands — who's on when, how to swap, and how alerts reach the right person — makes on-call sustainable. This guide walks you through how to set up an on-call schedule that works: rotation types, overrides, and what to look for in a tool.
Why You Need an On-Call Schedule
Without a defined schedule:
- The same people get paged — Usually whoever set up the alerts or the most senior person. They burn out and start ignoring alerts.
- Nobody knows who's responsible — "I thought you had it." Incidents slip through.
- Swaps and vacations are ad hoc — Last-minute DMs and hope someone remembers to update the alert routing.
An on-call schedule fixes this: it defines who is on call for which window (e.g. week, day, or shift) and gives you one place to see "who's on call now" and to manage overrides.
Types of On-Call Rotations
Weekly rotation
One person is on call for a full week (e.g. Monday 00:00 to next Monday 00:00). Common in small teams.
Pros: Simple, fewer handoffs, one person owns the week.
Cons: Long stretch; can be exhausting if incidents are frequent.
Good for: Teams of 3–8, moderate incident load.
Daily rotation
On-call rotates every 24 hours. Each person has a fixed day (e.g. Alice Monday, Bob Tuesday).
Pros: Shorter commitment per person, predictable.
Cons: Handoffs every day; incidents that span midnight can be messy if not clearly handed off.
Good for: Larger teams or high-incident environments where one week is too much.
Follow-the-sun (global)
Different people or regions cover different time zones so "business hours" are always covered without night shifts.
Pros: Fewer night pages, better work-life balance.
Cons: Needs enough people in each region; handoff and escalation rules must be clear.
Good for: Distributed teams with members in multiple continents.
Custom intervals
Some tools let you define custom rotation lengths (e.g. 3 days, 12 hours). Useful if weekly is too long but daily is too choppy.
Good for: Teams that have found a sweet spot (e.g. 2–3 days) through trial and error.
What to Include in Your Schedule
1. Clear time windows
Each rotation slot should have a start and end (e.g. "Jan 15 00:00 UTC – Jan 22 00:00 UTC"). Everyone should know when their shift starts and when they hand off.
2. Participants
List who is in the rotation. Only people who can actually respond (have access, know the system, and are willing) should be on the list. Add or remove people as the team changes.
3. Order or rotation logic
Define the order: who follows whom. Many tools support "rotate in order" so after Alice comes Bob, then Carol, then back to Alice. No ambiguity.
4. Overrides and swaps
Life happens: vacation, illness, travel. The schedule should support overrides so you can:
- Replace someone for a specific date range (e.g. Bob covers Alice Jan 20–22).
- Swap two people for a period.
Without overrides, people edit spreadsheets or hope someone remembers to change alert routing — error-prone and stressful.
5. Visibility: "Who's on call now?"
Someone (support, ops, or a stakeholder) will ask "who's on call?" The schedule (or the tool that runs it) should make the current and optionally next on-call person obvious. A single place to look reduces confusion.
How Alerts Reach the On-Call Person
The schedule alone isn't enough. Alerts (from your monitoring or ticketing system) must go to the person who is on call right now.
Two common patterns:
1. Alerts route to the schedule
Your monitoring tool (e.g. Webalert) has on-call schedules. You attach an escalation policy or notification channel to "the current on-call user" (or to the schedule). When an incident happens, the tool looks up who's on call and sends the alert to that person (email, SMS, Slack, etc.). No manual change when the rotation advances.
2. Alerts route to a channel; schedule is for visibility
Some teams send all alerts to a shared channel (e.g. #incidents) and use the schedule only to know who's responsible for responding. The on-call person watches the channel. This works but relies on people watching; it doesn't guarantee the right person gets a direct page.
Ideal: Alerts go directly to the current on-call person (or their escalation chain), and the schedule is the source of truth for "who that is." That way the right person is paged even if they're not in Slack.
Best Practices for On-Call Schedules
Keep the roster realistic
Only include people who can and will respond. If someone is overloaded or rarely available, don't put them in the rotation until they're ready — or use them as a later escalation step only.
Document handoff time
Agree on when handoffs happen (e.g. "Monday 09:00 local" or "midnight UTC") and whether the outgoing person stays responsible for in-flight incidents until they're resolved or handed off. Put it in a short runbook or schedule description.
Use overrides instead of ad hoc changes
Don't edit the "main" schedule for one-off swaps. Use overrides (or equivalent) so the base rotation stays correct and you have a record of who covered when.
Review and adjust
If one person is constantly overloaded or a rotation length is too long, change it. Review the schedule every quarter or when the team or incident load changes.
What to Look For in an On-Call Scheduling Tool
When choosing a tool (or using the one in your monitoring platform), check for:
- Rotation types — Weekly, daily, custom interval, and (if needed) follow-the-sun or multiple layers.
- Override management — Swap and replacement for specific dates without breaking the main schedule.
- Integration with alerting — Alerts automatically go to the current on-call user (or escalation policy that uses the schedule). No manual "change the Slack channel" each week.
- Visibility — "Who's on call now?" and optionally a timeline of who's on when (for the next few weeks).
- Coverage gaps — Warnings when no one is on call for a period (e.g. after removing someone and before adding a replacement).
Tools that combine monitoring and on-call schedules (like Webalert's Business plan) keep everything in one place: monitors trigger incidents, and the escalation policy sends alerts to the right person based on the schedule.
How Webalert Handles On-Call Schedules
Webalert's On-Call feature (Business plan) lets you:
- Create schedules — Weekly, daily, or custom rotation. Add participants and define the order.
- See who's on call — Current and upcoming on-call person; timeline view so you can plan.
- Manage overrides — Swap or replace someone for a date range (e.g. vacation, swap).
- Connect to escalation — Escalation policies can use the schedule so alerts go to the current on-call responder (and escalate to the next level if no acknowledgment).
- Pay per responder — Add-on pricing (e.g. €25/responder/month) so you only pay for people in the rotation.
Alerts from your monitors go to the right person based on the schedule — no manual updates when the rotation advances. See features for On-Call and escalation details and pricing for the Business plan and add-on.
Quick Checklist: On-Call Schedule Setup
- Choose rotation type (weekly, daily, or custom) and handoff time.
- List participants (only people who can and will respond).
- Define rotation order and create the schedule in your tool.
- Connect alerts to the schedule (escalation policy or channel that uses "current on-call").
- Set up overrides for known absences; document how to request a swap.
- Publish "who's on call" (tool link or status page) so the team and stakeholders know where to look.
Final Thoughts
An on-call schedule turns "someone should respond" into "this person is responsible this week." Use a rotation that fits your team size and incident load, support it with overrides and clear handoffs, and wire your alerts to the schedule so the right person gets paged every time.
Schedules and alerts in one place
See Webalert On-Call and escalation →
Check features and pricing. Business plan with on-call add-on.