When “three days” starts an argument
Someone files a ticket at 4:59 on a Thursday. The contract says “response within three business days.”
Half the room counts from Friday. Someone else starts after the weekend. A third person throws in a national holiday nobody remembered to block on the calendar.
Nobody is being lazy. The wording just never met a real calendar.
That gap is what we had in mind for the SLA deadline calculator—not another date picker, but a shared rulebook: pick a country (and region if you need it), pick how your team actually works, and let the tool walk forward in working days while weekends and holidays drop out automatically.
The part contracts leave implicit
Most SLAs are written in business days because they are trying to measure capacity, not elapsed wall time. The trouble is that “business day” is silent about:
- whether the clock starts on the day of receipt or the next working day
- which weekend definition applies (Fri–Sun vs regional norms)
- which holiday list applies when people sit in different places
- what happens when the “start” itself falls on a non-working day
Until those are pinned down, every spreadsheet is a private opinion.
HolidayDB’s model matches what we document on the calculator: you choose a working schedule (for example Mon–Fri, Mon–Sat, Sun–Thu, or seven-day operations that still skip holidays), and you choose where the work is anchored so public holidays are not guessed from memory.
“Day zero” is where teams quietly disagree
One subtle mismatch is whether the request date counts as the first day or as day zero before counting.
Our calculator treats the start date as day 0 and then advances N business days along valid working days. So a one-business-day SLA from a working Thursday is usually Friday, not “skip Thursday and land on Monday” unless Thursday itself is not a working day in your setup.
That is not the only convention in the wild, but it is consistent between the calculator UI and the GET /api/sla-deadline endpoint—which matters more than it sounds. When support, legal, and engineering all read the same output, you spend less time reconciling tools.
Regions matter even when the country label looks the same
National holidays are only part of the picture. Subnational rules—states, cantons, provinces—can split two desks in the “same” country into different working weeks during the same stretch.
If your SLA is tied to where the work is done or where the customer sits, bake that into the calculation up front. Otherwise you will ship a “global” policy that quietly favors one office’s calendar.
When you outgrow copy-paste
The on-page tool is for humans who need an answer in a hurry. When you need the same rules inside billing, ticketing, or compliance checks, wire GET /api/sla-deadline (see docs: SLA deadline) with the same parameters you would choose interactively—country, optional subdivision, start date, SLA length in business days, schedule, and language where supported.
Holiday calendars stay in sync with GET /api/holidays so you are not maintaining CSVs that go stale every budget season.
Try it
Open the SLA deadline calculator and run a few scenarios you have actually fought over in meetings—Friday starts, long weekends, “same” SLA in two regions. If the results match how your team intended the SLA to read, you have a baseline you can point to. If they do not, you have discovered an ambiguity worth fixing in the contract before the next escalation.