Software does not know it is a public holiday. If your shop, portal or booking system runs through the end of December while your development supplier is closed, the arrangement for those two weeks needs to be agreed in writing before they leave, and it needs to name people rather than companies.
This guide is for a manager who has to keep a service running through a period when almost nobody is at their desk.
Key takeaways
- Agree the holiday arrangement in writing before mid-December, including who is reachable and through which channel.
- Name individuals, not companies: an email address nobody is watching is not cover.
- Decide what counts as an emergency in advance, because at two in the morning nobody should be deciding that.
- Check that credentials and access exist outside one person's laptop before anyone goes away.
The four things to agree
Who is reachable, by name. One primary contact and one backup, with a phone number, not only an email address or a ticket system. Ticketing systems are excellent during working weeks and useless on 28 December.
What counts as an emergency. Write the definition down. A reasonable version: customers cannot buy, pay, log in, or a data problem is getting worse with time. Everything else waits. Without this, either everything becomes an emergency or nothing does.
Response times for the period. They will be longer than normal, and that is fine. What matters is that the number is agreed rather than assumed, and that you know what it is before you need it.
Who can authorise action. On your side as well. If your development partner needs approval to roll something back at eleven at night, name the person who can give it and make sure they know.
Check access before anyone leaves
The most common holiday incident is not technical, it is access. Someone is on a plane and they are the only person who can log in.
- Are hosting, domain, certificate and payment provider accounts reachable by more than one person?
- Do certificates or domains expire during the period? This is a small check that prevents a large problem.
- Is there a documented way to roll back the most recent deployment?
- Does anyone outside the supplier know how to put up a maintenance page?
- Is the monitoring sending alerts somewhere a human will see them, rather than to a channel nobody opens?
Freeze changes, and mean it
Agree a date after which nothing is deployed except fixes. In most businesses that is the middle of December.
The reason is the same as for any peak period: a change made just before everyone leaves is a change nobody is available to fix. The final deployment of the year should be early enough that it has been running normally for several days before the office empties.
Write the one-page plan
The deliverable is a single page, shared with everyone who might need it, containing the contacts, the escalation order, the definition of an emergency, the access details location, and the three or four things most likely to go wrong with what to do about each.
One page is the right length because it will be read on a phone by someone who is not at work.
After the period, review it
In early January, spend twenty minutes on what happened: what broke, who was contacted, how long it took, and what was missing. This is the cheapest possible input into next year's arrangement, and it is forgotten by February if nobody writes it down.
Related guides
- The question this one leaves open is answered in an app maintenance and support plan.
- Before committing to any of it, read what a non-technical owner should own.
- If the period is also your busiest trading week, preparing systems for peak sales week covers the load side.
If agreeing holiday cover exposes gaps in access, documentation or support, Discuss Your Plan.
Ali Boran Gazel