Most teams building an on-call rotation template in Google Calendar get the first two steps right and the third one wrong. Creating a shared calendar is easy. Inviting the team is easy. Expressing "four people, one week each, forever, handing off Monday morning" as a set of recurring events is where it falls apart, usually into a mess of one off entries that someone has to rebuild by hand every quarter.

The fix is recurrence arithmetic rather than more effort. This guide gives you three copy ready rotation templates for common team shapes, the exact recurrence settings each one needs, naming conventions that make the calendar useful during an incident, and an honest account of where the calendar approach stops working. If you want the broader setup walkthrough first, our guide on how to set up work rotations on Google Calendar covers the basics this post builds on.

Decide The Rotation Shape Before You Touch The Calendar

Every scheduling mistake downstream traces back to a shape decision nobody made explicitly. Settle these four things first, on paper, in about ten minutes.

Shift Length

Weekly is the default for a reason. It gives the on call engineer enough continuity to carry context across a multi day issue, and it produces a predictable cadence people can plan holidays around. Daily rotations spread the load more evenly but fragment context badly, so an incident that spans a night gets handed to someone who was not there for the start. Anything longer than a week tends to burn people out, particularly if your alert volume is high.

Handoff Time

Pick a specific time on a specific weekday and never move it. Monday morning at ten is popular and slightly wrong: it puts the handoff at the start of the week when everyone is also doing sprint planning. A handoff on Wednesday at ten has a quiet virtue, which is that the person going on call has the rest of the week at full attention, and the weekend falls in the middle of their shift rather than at the very end when they are exhausted. Either works. What matters is that it is fixed.

Coverage Window

Is the rotation genuinely 24 hours a day, or is it business hours with best effort overnight? Teams frequently avoid answering this, and the ambiguity surfaces at the worst time, when an alert fires at three in the morning and nobody is sure whether anyone was supposed to respond.

Time Zone Anchor

Set the calendar's time zone explicitly to the team's primary zone rather than leaving it to inherit from whoever created it. This matters more than it sounds, because of daylight saving. An event anchored to a zone that observes DST will shift by an hour relative to teammates in zones that do not, twice a year, silently. If your team spans regions that change clocks on different dates, expect a few weeks each year where the handoff drifts unless you anchor deliberately.

The Recurrence Math That Actually Works

Here is the core insight that makes the whole thing maintainable. For a rotation of N people with weekly shifts, you do not create one recurring event. You create N separate recurring events, each repeating every N weeks, each offset by one week from the previous one.

With four engineers, that means four events, each set to repeat every four weeks. Engineer A's series starts the first Monday. Engineer B's starts the second Monday. Engineer C's the third, engineer D's the fourth. Each series then repeats monthly on a four week cycle, and together they tile the calendar perfectly with no gaps and no overlaps, indefinitely.

The failure pattern this replaces is creating a single weekly recurring event and editing each instance to change the name. That works for about six weeks and then becomes unmaintainable, because every change to the rotation means editing every future instance individually, and Google Calendar's "this event and all following" behaviour will cheerfully overwrite the offsets you carefully set up.

Why This Survives Contact With Reality

The offset approach has three practical advantages. Adding a fifth engineer means changing four events from "every 4 weeks" to "every 5 weeks" and adding one new series, rather than rebuilding the calendar. Someone leaving means deleting their series and adjusting the interval. And because each person owns a distinct event series, you can add them as a guest on their own series only, so shifts land on personal calendars automatically without spamming everyone with every shift.

Three Ready To Use Templates

Template A: Four Engineers, Weekly, Full Coverage

The most common small team shape. Each engineer is on call one week in four, which works out to roughly thirteen weeks per year.

Event title: On-call: Primary, followed by the engineer's name
Start: Wednesday 10:00, team time zone
Duration: 7 days, ending Wednesday 10:00
Recurrence: Custom, repeat every 4 weeks, on Wednesday, no end date
Series offsets: Engineer A starts week 1, B week 2, C week 3, D week 4
Guests: Each engineer on their own series only, with "See guest list" turned off
Notification: Email 24 hours before, popup 1 hour before

Set the event to show as free rather than busy. An on call week should not block your calendar for meetings, and if it shows as busy your colleagues will stop being able to schedule anything with you for a quarter of the year.

Template B: Five Engineers, Weekday And Weekend Split

Weekends are the part people resent most, and splitting them separately spreads that load fairly instead of attaching it to whoever happens to hold the week. This shape uses two independent rotations on the same calendar.

Weekday series: five events, Monday 10:00 to Friday 18:00, repeating every 5 weeks, offset by one week each
Weekend series: five events, Friday 18:00 to Monday 10:00, repeating every 5 weeks, offset by one week each, but rotated two positions out of phase with the weekday series
Colour: distinct colours for weekday and weekend so the split is visible at a glance

The two position phase offset is the trick worth stealing. It means the person holding the weekday shift is almost never also holding the adjacent weekend, so nobody does eleven consecutive days of coverage.

Template C: Follow The Sun Across Two Regions

If you have engineers in two sufficiently separated time zones, follow the sun eliminates night pages entirely, which is worth considerable effort to achieve.

Region 1 series: 09:00 to 21:00 local, Monday to Friday, repeating every N weeks where N is the headcount in that region
Region 2 series: 09:00 to 21:00 local, offset so the two windows abut with a small overlap
Overlap: deliberately build in 30 to 60 minutes where both are on call, as handoff time
Weekend: handle separately, because five day follow the sun leaves Saturday and Sunday uncovered

Be realistic about the prerequisite. Follow the sun needs genuine coverage depth in both regions. Two engineers in one region and one in another is not follow the sun, it is one person with no backup wearing a more flattering label.

Naming And Description Conventions That Pay Off

The calendar event is often the first thing someone looks at during an incident, frequently on a phone, frequently at an unreasonable hour. Optimise for that moment.

Use a consistent title format that reads well when truncated, because mobile calendar views cut titles short. Putting the role before the name means "On-call: Primary" survives truncation while "Jamie Okafor is on call this week as primary" becomes "Jamie Okafo..." and tells you nothing.

Put working context in the event description, not just the name:

Link to the runbook index
Escalation path with the secondary's name and how to reach them
Link to the primary dashboard
Any known ongoing issues or planned maintenance during this shift
A one line note on what changed since the last handoff

That last one is the difference between a calendar that documents who is responsible and a calendar that actually helps someone respond.

Test The Tiling Before You Trust It

Offset recurring series are easy to get subtly wrong, and the errors do not show up for weeks. A one week gap in March is invisible in September. Spend five minutes validating before you announce the rotation.

Scroll Forward Three Months

Switch to the month view with only the rotation calendar visible and page forward through the next twelve weeks. You are looking for exactly one on call event covering every day. Two overlapping events mean an offset is wrong. A bare day means a series starts later than you thought, which usually happens because Google Calendar anchored the recurrence to the date you created the event rather than the date you intended.

Check The Cycle Boundary

The most common defect appears where the cycle wraps, when the last person hands back to the first. If engineer D's series and engineer A's series were created on different days, the wrap can land a day early or late. Verify the specific handoff from the last person in the cycle to the first, at least twice.

Confirm It Looks Right To Someone Else

Sharing permissions and guest settings behave differently for the calendar owner than for everyone else. Ask a teammate to confirm they can see the full rotation and that their own shifts appear on their personal calendar. Owners routinely cannot tell that a calendar was never actually shared, because it looks complete from where they are sitting.

Plan For Holidays Before They Arrive

Public holidays do not respect your rotation, and the person whose week contains a four day national holiday is carrying a meaningfully heavier shift than the person whose week does not. Look ahead at the next two quarters, identify the shifts that collide with holidays, and either rebalance them in advance or agree explicitly that the burden evens out over a year. Doing this in advance is a five minute conversation. Doing it the day before is a negotiation nobody enjoys.

The Swap Problem

Every rotation meets reality within about three weeks, in the form of a shift swap. Someone has a wedding, a flight, a sick child. This is where the calendar only approach starts showing its limits, and it is worth understanding precisely why rather than discovering it during an incident.

When you edit a single instance of a recurring event, Google Calendar detaches that instance from the series. That is usually what you want, but it has consequences. The detached instance no longer inherits future changes to the series. If you later adjust the rotation pattern, the swapped week silently keeps the old arrangement. Teams accumulate these detached exceptions over a year and eventually cannot tell whether the calendar is accurate.

The deeper problem is that the swap has to be reproduced everywhere else. The calendar now says Priya is covering Thursday. Your alerting tool still thinks it is Marcus. Your Slack user group still mentions Marcus. Unless every one of those is updated by hand, the swap exists socially but not operationally, and the alert at two in the morning goes to someone on a plane.

Where Calendar As Source Of Truth Breaks Down

Google Calendar is an excellent way to see a rotation. It is a poor place to define one. The distinction matters:

No alert routing. The calendar knows who is on call. Your monitoring does not read the calendar, so alerts route by whatever was configured separately.
Swaps are manual and lossy, for the reasons above.
No self service. Someone with edit rights has to make every change, which in practice means one person becomes the scheduling bottleneck.
Onboarding is a rebuild. Adding a person means changing the recurrence interval on every existing series.
No overrides as a first class concept. A two day holiday cover is expressed as an awkward edit rather than a temporary override with a clear start and end.
No audit trail. When you need to know who was on call at 03:14 six weeks ago, edited recurring events give you a version of history that may have been rewritten since.
No escalation. A calendar cannot notice that nobody acknowledged and move to the next person.

Keeping The Calendar Without The Maintenance

The resolution is not to abandon Google Calendar. People genuinely want their shifts in the calendar they already live in. The resolution is to stop making the calendar the system of record and make it a view that updates itself.

That is how Pagerly's rotations are designed to work. The rotation is defined and managed in Slack, and Google Calendar is written to automatically using your calendar ID, so every shift appears as a normal calendar event on the right person's calendar without anyone maintaining recurrence rules. When a swap is approved through the cover request flow in Slack, the calendar updates immediately, and so does the alert routing, because they are the same underlying schedule rather than two systems you keep in sync by hand.

The other half of the problem is the mention. Slack user group sync keeps a group like @oncall pointing at whoever currently holds the shift, so anyone in the company can reach the on call engineer without consulting a calendar at all. Shift reminders land in Slack at one day, twelve hours and six hours before a shift starts, alongside the calendar's own notifications.

Setup Checklist

Create a dedicated shared calendar, not entries on personal calendars
Set the calendar time zone explicitly to your primary team zone
Share with a Google Group rather than individuals so joiners inherit access
Build N series repeating every N weeks, offset by one week each
Add each engineer as a guest on their own series only
Set events to show as free, not busy
Use a truncation friendly title format with the role first
Put runbook links and the escalation path in every event description
Set reminders at 24 hours and 1 hour
Decide and write down the swap process before the first swap request
Review the calendar in sprint planning so conflicts surface early
Audit quarterly for detached instances that have drifted from the pattern

The Takeaway

A Google Calendar on-call rotation template is mostly a recurrence problem, and the N events repeating every N weeks pattern solves it cleanly for any team size. Get the shape decisions made explicitly, anchor the time zone, put real context in the descriptions, and the calendar becomes genuinely useful rather than decorative.

What the calendar cannot do is route an alert, follow a swap, or escalate when nobody answers. Those need a schedule that other systems can read. Keep the calendar as the view your team looks at, and let something else own the truth.

Want your rotation in Google Calendar without maintaining recurrence rules? Pagerly manages the schedule in Slack and keeps Google Calendar current automatically, including swaps. Get started free.