On-call rotas that survive holidays, timezones and sick days
Most rotas fail at the edges: a public holiday, a clock change, a sick engineer at 02:00. Here is how to design a weekly rota that still pages someone.
A rota that works on a normal week is the easy part. It breaks on the first bank holiday, the weekend the clocks change, or the night someone wakes up with a fever and nobody knows. Design for those edges first and the normal week takes care of itself.
Start from the failure, not the calendar
An on-call rota has one job: when an alert fires, exactly one named person knows it is theirs. Every way a rota fails is a way of breaking that sentence.
- Nobody is responsible: a gap in coverage, an unfilled weekend, a departed engineer still on the schedule.
- Two people are responsible: overlapping shifts where each assumes the other is looking.
- The wrong person is responsible: a shift that drifted by an hour because of a timezone or daylight saving mistake.
- Someone unreachable is responsible: asleep through the page, on a plane, or off sick.
Holidays, timezones and sick days map onto these four. The fixes below are organised the same way.
One owner per hour, always
Overlap feels safe. In practice it is the opposite: two people on call means two people who can reasonably decide the other one has it. Pick one owner for every hour and make the handover a hard edge.
That rule has a useful side effect. If the rota can only express one person per hour, then a gap is visible as an empty cell rather than hidden inside a rule. Read your rota as a grid once a month and look for blanks. A weekend nobody claimed is much easier to spot in a grid than in a list of rotation rules.
Avoid shifts that wrap midnight in your planning, too. A shift that runs 18:00 to 08:00 is hard to reason about on a day with a clock change and hard to hand over. Splitting it into an evening segment and a morning segment per day says the same thing and is easier to check.
Timezones: store the zone, not the offset
There are two separate timezone problems, and teams mix them up.
The first is which zone the rota is written in. If a shift is stored as "09:00 UTC+1", it is wrong for half the year in any place that observes daylight saving time. If it is stored as "09:00 Europe/Amsterdam", it stays at 09:00 local time when the clocks change. Store the IANA zone name, not a numeric offset.
The second is who is reading it. A distributed team will read the rota in several zones. Pick one zone for the rota itself, write it at the top of the page, and let people convert. A rota that silently renders in each viewer's local time causes handover arguments: two people looking at the same cell disagree about when it starts.
On the two Sundays a year when clocks change, check the rota by hand. One of those days has 23 hours and the other 25. A shift defined as "8 hours from midnight" ends at a different wall-clock time than a shift defined as "00:00 to 08:00". Decide which one you mean, and write the shifts as wall-clock times.
Holidays: edit the week, then put it back
A repeating weekly pattern is the simplest rota that works. It has no end date and no calendar of exceptions, which is exactly why it is easy to keep correct. The price is that a public holiday or a planned absence is not a special case in the pattern. You handle it by changing the week for the duration and changing it back.
That works if you make it a routine rather than a memory test:
- Keep a shared list of known absences for the next quarter: holidays, conferences, leave.
- The Friday before an affected week, someone edits the rota. Put it on a recurring calendar reminder, not on goodwill.
- After the week passes, restore the normal pattern. The common failure is a temporary edit that quietly becomes permanent.
- If one person is covering for another, say so in your team channel. The rota names the owner. The channel explains why.
The second-most-common holiday failure is the long weekend nobody thought of as special. If your company is in one country but your engineers are in three, there is almost always some holiday inside any given month. Ask each person for their local ones once, and write them into the absence list.
Sick days: you cannot plan them, so plan the fallback
Nobody schedules a fever. What you can schedule is what happens when the person on call does not respond. There are two layers.
Swap norms. Agree in advance that anyone can ask anyone to take a shift, and that the person asking edits the rota, so the rota reflects reality within the hour. The rota should be the source of truth, not a message in chat that only two people saw.
Escalation. Assume the page will sometimes go unanswered, for any reason: a phone on silent, a dead battery, a tunnel. The alert should not stop at the on-call person. Add a wait step and then a second recipient who is not on the same shift. This is the same design as in designing an escalation policy that does not wake the whole team: the rota says who goes first, the escalation says what happens if they do not answer.
Pair that with acknowledgement. If the first person claims the alert, escalation stops. If they do not, the second person is paged after the wait. Pick the wait deliberately. Ten to fifteen minutes is a common starting point for a customer-facing outage, but it depends on how quickly you need a human looking. Acknowledgement is what makes a short wait safe.
A gap should fall back, never fail
Even a well-kept rota will have a blank hour sometimes. The question is what an alert does when it finds one. The wrong answer is to drop it. The right answer is to send it to a fixed fallback: a named lead, a shared inbox or a team address that someone always reads.
The fallback is not a replacement for a complete rota. Treat any alert that landed on the fallback as a bug in the schedule and fix the blank that caused it.
How this looks in Hesklo
Hesklo's on-call scheduling follows the shape above. You paint a repeating week, one person per hour, stored against the planner's timezone so shifts do not move when the clocks change. An email step can be set to use the schedule, and if nobody is on call when it fires, the email goes to its own chosen recipient instead. Combine it with a wait step and a second email for escalation. On-call scheduling is part of the Team and Business plans, as listed on the pricing page, and it works alongside team accounts since the people on the rota need to be members of the account.
A monthly rota check
Fifteen minutes on the first working day of the month is enough.
- Open the rota as a grid. Is every hour of the next four weeks owned by exactly one person?
- Does everyone on it still work here, and still want to be on it?
- Is the rota's timezone written down, and is it the one you meant?
- Is there a clock change in the next month? If so, read the affected shifts by hand.
- Which holidays and leave fall in the next month? Has someone been assigned to edit the rota for each?
- Does every paging path have a fallback recipient and a second step if the first person does not acknowledge?
- Did any alert land on the fallback last month? Find out which hour was blank.
If you do nothing else, do the last item. Alerts that reached the fallback are the rota telling you where it is wrong, and they are a free audit of everything above.