What Should an Automation Do on a Public Holiday?

What should an automation do on a public holiday?

Usually nothing, and then catch up deliberately. Most scheduled automations send, chase, or escalate something to a human, and a human who is not working cannot act on it. The right default is to hold the work and release it on the next working day, not to run blindly.

This sounds like a small edge case until you watch a payment reminder fire on a national holiday, or an escalation alert page someone at midnight because the schedule was written in the wrong timezone. Both are avoidable.

Working from Bengaluru with clients in other time zones, I hit this constantly. Two countries, two holiday calendars, two definitions of the working week. The automation has no idea about any of it unless you tell it.

Why does calendar awareness matter more than it sounds?

Because scheduled automations usually create obligations. A reminder expects a response. A report expects a reader. An escalation expects an owner. When the human side of that contract is absent, the automation is not saving time, it is generating a backlog nobody asked for.

There is also a trust cost with customers. An invoice chase that arrives on a holiday reads as automated indifference, and the recipient is right. Nobody chose to send it that day, which is exactly the problem.

The third cost is noise. When alerts fire on days nobody is watching, people start ignoring the channel, and an ignored alert channel is worse than no alert channel.

What is the difference between skipping and deferring?

Skipping means the run never happens and the work is lost. Deferring means the run is postponed and happens later. Most automations should defer, but a few genuinely should skip, and confusing the two is where the damage comes from.

A daily summary should skip. Nobody wants four days of stale summaries on Monday morning, and the information has already been superseded.

A payment reminder, a renewal notice, or a customer facing follow up should defer. The obligation did not disappear because the office was closed, and dropping it silently is a worse failure than sending it late.

How do you decide which one applies?

Ask whether the run is reporting or acting. Reporting runs describe a state that will still be true later, so skipping is safe. Acting runs create or advance something, so they must defer or they lose work.

The second question is whether the run has a deadline attached. Anything tied to a contractual or regulatory date defers to the next working day rather than skipping, and someone should be told that it moved.

Write the answer next to each automation when you build it. One word, skip or defer, in the same note where you record the owner. It takes seconds and it prevents the argument later.

Where should the holiday calendar actually live?

In one place that every automation reads, not hard coded into each one. A single table of non working days, with a country or region column, is enough, and it means next year's update is one edit rather than fifteen.

I keep this as a small table in Airtable for the systems that already live there, and read it from the workflow before deciding whether to proceed. Google Calendar works equally well if that is where the business already keeps its calendar.

Source the dates from an authority you trust and check them annually, because published holiday lists change and some are declared with little notice. I would not trust any list I had not refreshed this year, including one I wrote myself.

What about timezones and daylight saving?

Store schedules in UTC and convert for the business rule, not the other way round. A schedule written in local time will silently shift twice a year in any country that observes daylight saving, and the shift is usually noticed by a customer before it is noticed by you.

The subtle failure is a job scheduled for late evening or early morning local time. After a clock change it can jump across midnight and land on a different calendar day, which quietly breaks anything that computes a date from the run time.

The fix is to anchor on UTC and to decide explicitly which timezone defines a business day for each customer. If you serve two regions, that is two rules, and pretending otherwise is how weekend sends happen.

What breaks at month end and quarter end?

Anything that assumes a fixed day exists. A job scheduled for the thirty first misses several months entirely, and a job scheduled for the first of the month will land on a weekend or a holiday roughly a third of the time.

The safer pattern is to express the rule the way finance would say it. Last working day of the month. First working day after the quarter closes. Then compute that date from the calendar rather than hard coding a number.

Month end is also when volume spikes, so a deferred job that lands on the same morning as three others can hit limits it never hits otherwise. Spread deferred work across the morning rather than releasing it all at nine.

How do you test this without waiting for a holiday?

Add a fake holiday to the calendar table for tomorrow and watch what happens. That single test tells you whether your skip and defer logic works, and it takes minutes rather than waiting for a real closure to discover the answer.

Test the day after as well, because the interesting bug is usually in the catch up rather than the pause. Two deferred runs releasing at once, or a deferred run that recalculates its date and defers again forever, are both common and both invisible until they happen.

This is the kind of check that belongs in the same pass as the rest of your automation hygiene, alongside knowing whether an automation is still working at all.

Who should be told when something is held?

The owner of the automation, quietly, and the affected human only if the delay changes what they should do. A held run that resumes cleanly needs a log line. A held run that will miss a commitment needs a person.

The log line matters more than it looks. Without it, a quiet holiday pause is indistinguishable from a silent failure, and you will spend an hour investigating something that worked exactly as designed.

If the automation is client facing, say so in the handover notes. A client who knows that reminders pause on their holidays will not raise a ticket the first time it happens, which is the kind of small clarity that keeps a system trusted. It belongs in the same document as the handoff documentation you write for clients.

What should you do next?

Pick the automation that touches customers most often and answer one question: what does it do on a day nobody is working. If you cannot answer, that is your next hour of work, and it starts with a single table of non working days.

Then mark every scheduled automation skip or defer, and add the fake holiday test to your calendar for next week. Both changes are small, and together they remove an entire category of embarrassing sends.

If you want help auditing your scheduled workflows for calendar and timezone assumptions, reach out. It is a short piece of work that pays for itself the first time a holiday lands mid week. Let's chat.