Skip to main content
Back to Blog
Automation5 min read26.07.2026Max Fey

Your workflow counts days. Your contract counts working days.

Working days and public holidays break automated deadlines: why a 48 hour timer is not a two working day SLA, why the bug survives for years without a single error in the log, and how to calculate deadlines that hold up.

Your workflow counts days. Your contract counts working days.

A support team we worked with promises a reply within two working days. That promise lived in an automation as a 48 hour timer. A ticket arrives Friday at 4 p.m., the timer runs out Sunday at 4 p.m., and the escalation lands in a channel nobody reads on weekends. By Monday morning the ticket is already marked as breached. The quarterly SLA report made the team look worse than it had actually performed, and it took two quarters before anyone questioned the number instead of the team.

No step failed. The automation did exactly what someone typed into it two years earlier.

Adding days is easy. Calendars are not.

Every no-code platform makes future dates trivial. addDays(now, 14), one field, done. That convenience is why the same expression shows up in every scenario that involves a deadline, and why nobody spends a second thinking about it.

Working days cannot be calculated. They have to be looked up, and in Germany the lookup depends on where the recipient sits. Corpus Christi is a public holiday in Bavaria and North Rhine-Westphalia but a normal working day in Berlin. Reformation Day applies in nine of sixteen states. One holiday in the calendar applies to a single city. Any automation that promises a date needs a holiday list that also knows the location it is calculating for.

The places it usually hides

Dunning is the loud one, because customers call. The quiet ones tend to run for years:

  • Renewal and expiry warnings that fire 24 hours in advance land on a Sunday. On Monday at nine they are already buried.
  • Return and withdrawal windows are usually miscalculated in the company's own favour, which is the more expensive direction to get wrong.
  • Onboarding sequences assign a task on day 3 after signature. When day 3 is December 26th, the task ages out in a list nobody reopens in January.
  • Shipping estimates in a confirmation email promise two days on December 23rd. The email is automated, the promise is not.
  • Internal approval chains escalate after "three days" and reach a manager who has been on leave since Thursday.

Why it survives so long

Public holidays are rare. Nine to thirteen days a year depending on the state, plus weekends. An automation that runs daily produces the right answer for well over ninety percent of the year. Whoever tested it did so on a Tuesday in March, and on a Tuesday in March it works.

There is also nothing to monitor. No red run, no log entry, no alert. The workflow behaves. The only detector is a human outside your company, and that person does not report a date calculation bug. They complain about the dunning notice.

What we do instead

Start with the contract. The formula comes afterwards. Does the agreement, the terms, or the service promise say days or working days? Both are defensible. The workflow simply has to compute the one that was promised. In most companies we audit, both readings exist side by side in different documents, and nobody ever decided which one governs.

Then keep one holiday source. A single table with date, region, and reason, filled at least two years ahead, owned by a named person who tops it up each autumn. Company shutdowns and bridge days belong in the same table. Two lists in two places are worse than one, because within a year only one of them is still maintained.

On top of that, build one shared helper: add N working days, and next working day. A sub-workflow in n8n, a dedicated scenario behind a webhook in Make, or a short function. It only has to exist once. Seven copies across seven scenarios means the next legislative change gets applied to two of them.

For anything that reaches a human, a sending window often beats holiday logic entirely. Monday to Friday, 8 a.m. to 6 p.m. Whatever falls outside waits and goes out the next working morning. It costs a few hours of latency and prevents the kind of message that arrives at 9 p.m. on a public holiday.

One thing worth checking this week

Go through your live scenarios and list every place a date gets calculated. addDays, dateAdd, delay steps in email sequences, anything with a plus and a number of days. For each one, ask what happens when the result lands on a Saturday, a Sunday, or a national holiday.

The review takes about half a day. It usually turns up somewhere between three and ten spots where the honest answer is that a customer would notice before you did. A calculated date looks like arithmetic. To whoever receives it, it is a promise.

#Werktage#Feiertage#Fristen berechnen#Mahnwesen#SLA#Automatisierung#Make#n8n