All Saints’ Day falls on a Sunday this year. For Bavaria, Baden-Württemberg, North Rhine-Westphalia, Rhineland-Palatinate and Saarland that means the following Monday is a public holiday — or, depending on the state, an ordinary working day. For a company in Neuburg a.d. Donau with field service in Nuremberg, Augsburg and Ingolstadt that is routine. For a company with sites in Bavaria and Lower Saxony it turns a harmless date into a duty-roster puzzle.
The problem is not All Saints’ itself. The problem is that between All Saints’ and the first Advent there are three weeks of partial holidays, bridge days and regional specifics — and that most IT departments head into this phase with a duty roster designed for the summer holiday season. What worked in June does not automatically work in November.
This article is a practical playbook for the holiday weeks until the end of the year, written from a consulting perspective. No vendor pitches, no product list — a checklist and a few lessons from incidents we have seen at customers over the past few years.
IT standby on holidays — the core problem
In the vacation context we already described in detail how on-call works with a small team. Much of it applies to holidays too, but with three key differences:
Holidays are shorter and denser. A summer vacation runs two to three weeks straight. A November holiday phase is one day here, two days there, a long weekend in between. That means the on-call roster rotates every few days, handovers happen more often, the risk of overlooking something rises.
Holidays are regional. All Saints’ Day in Bavaria, Repentance Day (Buß- und Bettag) in Saxony, Reformation Day in the five northern states — anyone with sites in several German federal states not only has to run their own roster but also know when the supplier in the neighbouring state is working. A spare part ordered on Monday from a Bavarian dealer only ships on Tuesday.
Holidays sit at the edge of the backup window. Many backup jobs are timed so that weekends pull full backups and weekdays run incrementals. If one weekday drops out as a holiday, the windows shift; if two drop out, the incremental chain has gaps. Without active verification you only notice at the next restore attempt.
Monitoring escalation: who gets the alarm, who forwards
The most common mistake we see in holiday incidents is that the monitoring alarm goes out but nobody reads it. Not because nobody is on call, but because the alarm goes to a distribution address whose members are all off simultaneously in different states.
A clean escalation chain has three levels:
- Primary alarm by email to the IT mailbox. In normal operation this mailbox is checked regularly. On holidays it is unreliable.
- Secondary alarm by SMS or push to a dedicated on-call number. This number rotates with the duty roster — not the email distribution, only the SMS forwarding.
- Tertiary alarm by voice call from the monitoring system through a voice-gateway service, if primary and secondary are not acknowledged within 15 minutes. Reliably wakes someone up, costs money and should only be active for truly critical alerts (storage pool critical, hypervisor outage, full network failure).
In our own practice with Zabbix and Grafana Alerting we use an external SMS gateway service for stage 2 that rotates the number automatically based on the current on-call roster. For stage 3, a simple Twilio or Sipgate integration is enough — the cost per triggered call is a few cents, over a full year it adds up to a two-digit euro amount.
Push instead of SMS: when the switch pays off
Push notifications over dedicated apps (Pushover, Ntfy, Signal bot) are cheaper than SMS and more reliable than email — provided the on-call phone has reception. In practice we recommend push as the main stage-2 channel, SMS as a fallback if the phone has no data signal. In the rural Bavarian areas behind Neuburg, that is not a hypothetical.
Duty roster for the holiday week: planning realistically
For small IT teams (one to three people) a rigid rotation roster rarely makes sense for the holiday week — the team is simply too small. What does work:
Model A — fixed on-call person with external fallback. One person is on call on a holiday, with DATAZONE support as a fallback if needed. The cheapest model and sufficient for many mid-market customers with standard setups.
Model B — rotation in a two-person team with scheduled handovers. Two people alternate over long weekends with a handover the previous day at 5 pm as a 15-minute call. A short status document (open tickets, running jobs, specifics) is maintained. Works for teams that already collaborate closely.
Model C — full on-call outsourcing to an external provider. For companies where the internal IT cannot or should not provide standby, we take over holiday on-call alerting under contract. This pays off especially for customers with TrueNAS estates or more complex Proxmox clusters where deep product knowledge is needed when an incident fires.
Across all three models the same rule applies: the duty roster must be written down and reachable. Not in a Google Calendar the deputy has no access to, but in a shared document or on a sheet of paper next to the server rack.
Supplier reach: who answers on a holiday
A point that is often overlooked: if hardware fails on a holiday, the best on-call is of little help if the supplier is unreachable. Before the holiday week it is worth a quick check of your contract partners:
- Hardware dealers with NBD SLA (next business day): does the holiday count as a “business day” or not? Most SLAs exclude federal holidays — regional ones like All Saints’ are handled differently from vendor to vendor.
- TrueNAS hardware support from iXsystems: the current M30 and M40 enterprise systems run under the service window defined in the support contract. In Germany, iXsystems treats All Saints’ and Repentance Day as local holidays. Enterprise support and hardware packages are structured so that regional holidays are considered.
- Data centre co-location: access procedures on holidays are often restricted. Anyone who needs to swap a dead unit on a holiday needs pre-registration, not a walk-in.
- Internet providers with SLA: usually the holiday regulation of the provider’s registered office applies, not the customer’s. Worth checking.
Our recommendation to all customers before the holiday week: print a supplier overview with phone numbers, SLA status and specifics for the current month and keep it at the IT workstation. Two minutes of prep that saves a lot of time in an incident.
Backup windows and holidays: the silent mistake
Of all the issues we meet in holiday-time incident post-mortems, the backup window is the most insidious. Because it does not show up immediately — the backup job reports “success” because it ran through cleanly. Except that “ran through cleanly” on a holiday can mean something different from a normal weekday.
Typical failure patterns we see in audits:
- Snapshot rotation keeps 7 days. With two holidays in one week and a weekend in between, effective weekday history drops to 2–3 days. Too little for a ransomware case with delayed detection.
- Replication job to an offsite target runs at 2 am. On the holiday the network is relaxed and the job finishes quickly — but on the Monday after the holiday it competes with regular weekday traffic and slips, without anyone having an alert rule for the delay.
- S3 replication to a hyperscaler runs on a monthly cycle. If the cycle day falls on a holiday it is often postponed — but the monitoring sees “not yet due” and raises no alarm.
What we recommend: check the backup dashboards manually before every holiday phase. Five minutes for a look at TrueNAS, Veeam or Proxmox Backup Server. Last full backup, last successful replication, pool fill level, snapshot count. If you have not done this in October, do it this week.
And: a restore test on one of the quiet holidays is a good idea. Not in production, but in the test environment from our restore drill article. If the holiday is quiet anyway, the hour is well spent.
Concrete dates for the rest of 2026
For the remainder of 2026 these are the critical dates from an IT perspective:
- 1 Nov (Sunday) — All Saints’ Day in Bavaria, BW, NRW, RP, SL. Monday a working day, but with reduced external supplier availability in these states.
- 18 Nov (Wednesday) — Repentance Day (Buß- und Bettag) in Saxony. A holiday for Saxon sites, not nationwide. Suppliers in Saxony limited.
- 22 Nov (Sunday) — Totensonntag (Sunday of the Dead). Not a statutory holiday, but traditionally quiet; some suppliers reduce staffing.
- 24–26 Dec — Christmas core time, nationwide. We publish a dedicated playbook for this at the start of December.
- 31 Dec and 1 Jan — New Year’s Eve and New Year’s Day. In our experience the lowest-risk phase of the entire holiday period, because attackers are also on break. Keep monitoring active anyway.
FAQ
Does 24/7 on-call pay off for a small mid-market company?
Usually not — unless the business directly depends on IT operations (production control, logistics centres, online shops with night-time revenue). For plain office mid-market firms, a weekday standby from 7 am to 7 pm plus a clearly defined escalation path outside those hours is usually enough.
How often should the on-call roster be updated?
At least quarterly, in phases with many holidays (spring, late autumn) monthly. What matters is not absolute frequency but that the current document is in the hands of everyone involved — including the deputy and the external provider.
What happens if a holiday monitoring alarm reaches nobody?
Ideally the incident lands with an external provider under model C that is also staffed on holidays. In models A and B the tertiary alarm stage (voice call from the monitoring system) should make sure someone wakes up. If every stage completes and nobody reacts, the problem is organisational rather than technical — and needs to be discussed in the team after the holiday.
Should we introduce a patch freeze before the holidays?
For critical production systems yes, at least 48 hours before the first holiday of the phase. For standard office systems and workstations no — updates should keep running. Between those two there is a grey zone; the decision depends on the system and its change history. When in doubt, prefer the freeze and push open changes to after the holidays.
How do I test whether my alert chain actually works on holidays?
Two to three weeks before the holiday phase, trigger a test alarm that passes through all three stages. If push does not arrive, the SMS gateway is misconfigured or the voice call ends up on an old number, you catch it now — not in a real incident. These 20 minutes of practice save hours when it counts.
What does DATAZONE actually do for customers in this phase?
For customers with a support contract we take over holiday on-call alerting, check backup dashboards manually before the phase and remain reachable for incidents on federal holidays. The exact scope depends on the individual contract — existing customers are best off calling us directly, prospects reach out via the service page.