The fields of a usable on-call calendar template
A schedule is more than a list of names. If any of the fields below is missing, someone will ask for it during an incident, which is the worst moment to be looking it up.
| Field | What it holds | Why it matters |
|---|---|---|
| Service or team | The services this rota covers | Alerts route to a schedule through the service, so the scope has to be explicit |
| Layer | Primary, secondary, or manager | The escalation policy points at layers, not at people |
| Shift start and handoff time | Day, hour and time zone | Ambiguous handoffs create gaps where nobody is on call |
| Rotation length | One day, one week, or custom | Decides how often each person carries the pager |
| Participants in order | The people in the rotation | Order determines who is next after each handoff |
| Overrides | One-off replacements with dates | Holidays, sick days and swaps without editing the rotation |
| Contact methods | Push, SMS, voice, email | Paging must reach people when chat is down |
Keep the time zone on every row. A handoff written as "Monday 09:00" means two different moments for a team in Berlin and Chicago, and the gap between them is exactly where a page gets lost.
Sample on call schedule for a single-site team
The weekly rotation is the default for a team of six to eight engineers in one region. Each person holds primary for a week, then secondary for the following week, so the secondary always has fresh context from the week before.
| Week | Primary | Secondary | Handoff |
|---|---|---|---|
| Week 1 | Engineer A | Engineer F | Monday 10:00 local |
| Week 2 | Engineer B | Engineer A | Monday 10:00 local |
| Week 3 | Engineer C | Engineer B | Monday 10:00 local |
| Week 4 | Engineer D | Engineer C | Monday 10:00 local |
| Week 5 | Engineer E | Engineer D | Monday 10:00 local |
| Week 6 | Engineer F | Engineer E | Monday 10:00 local |
Why hand off at 10:00 on a Monday rather than midnight on Sunday: the outgoing and incoming engineer are both at work, can talk through open issues, and nobody starts a week of pager duty asleep. Avoid Friday handoffs, because the incoming person inherits the weekend before they have seen a single alert.
Google's Site Reliability Engineering book gives a useful sizing reference. It suggests that engineers spend no more than about a quarter of their time on call, and derives from that a minimum of eight engineers for a single-site team running a primary and secondary rotation around the clock, or six per site when two sites share the load. Smaller teams can still run a rota, but they should know they are above that ceiling and compensate with fewer alerts, business-hours coverage for lower severities, or time off after heavy shifts.
On call rotation schedule template for distributed teams
If your engineers sit in two or three regions, a follow-the-sun layout lets each region cover its own daytime, so nobody is paged at night for routine incidents. The template below uses three regions with eight-hour shifts; two regions work the same way with twelve-hour shifts.
| Shift (UTC) | Region | Primary layer | Handoff note |
|---|---|---|---|
| 00:00 to 08:00 | Asia Pacific | APAC weekly rotation | Written summary posted to the team channel at 08:00 UTC |
| 08:00 to 16:00 | Europe | EMEA weekly rotation | Written summary posted at 16:00 UTC |
| 16:00 to 24:00 | Americas | AMER weekly rotation | Written summary posted at 24:00 UTC |
Each region keeps its own weekly rotation inside its shift, so a follow-the-sun schedule is really three schedules stitched together by time windows. Write the windows in UTC and let every person see them converted to their own time zone. Weekends deserve a separate decision: some teams keep follow-the-sun seven days a week, others collapse to one region with a lighter alert policy on Saturday and Sunday.
The handoff note is what makes follow-the-sun work. A good one lists open incidents, anything silenced or in a maintenance window, deploys in progress and alerts that looked noisy. Without it, each region rediscovers the previous region's problems from scratch.
Overrides, swaps and on-call load
A template is only as good as the rules around it. These are the ones that prevent most on-call friction.
- Swaps are made as overrides, not by editing the rotation. The rotation stays predictable and the swap has a clear start and end.
- Nobody holds primary for two consecutive weeks unless they asked to.
- The secondary is a different person from the primary's manager, so escalation does not jump straight to management by default.
- New engineers shadow a full rotation as secondary before they take primary.
- Load is reviewed monthly: pages per shift, pages outside working hours and time spent on incidents. The same SRE guidance recommends keeping the number of incidents per shift low enough that each one can be handled properly and followed up with a postmortem.
- People who were paged heavily overnight get the next morning back, and it is written into the policy rather than negotiated each time.
If you want to compare different shift patterns (daily, weekly, split weekday and weekend, or on-call pairs), the on call rotation guide walks through six of them and when each one fits.
From a spreadsheet to a schedule that pages people
Many teams start with a spreadsheet or a shared calendar, and that is fine for the first weeks. The limits show quickly: a spreadsheet cannot page anyone, it does not know about overrides, and it drifts from reality the first time two people swap a shift in chat.
A schedule becomes useful when the alerting system reads it. The alert arrives, the service points to an escalation policy, the policy points to the primary layer of the schedule, and the person on shift at that exact minute is paged. If they do not acknowledge within the timeout, the secondary layer is paged next. That chain is what you are really designing when you fill in the template above.
Turn the template into live on-call scheduling
In IncidentBot, each table on this page is a schedule with layers: weekly or daily rotations, handoff times in any time zone, follow-the-sun windows, overrides and swaps, and calendar sync so every engineer sees their shifts next to their meetings. Escalation policies point at the layers, and paging goes out by mobile push, SMS, voice, email and Slack, so it does not depend on chat being up. The on-call load report shows who is carrying the pager most. See how it fits together on the on call scheduling software page, check plans on pricing, or run a sample incident on the demo to watch a schedule and an escalation policy page someone in real time.