We had a job scheduled to run every weekday at 9 AM. Cron handled that part fine, right up until Thanksgiving, when it ran anyway, into an empty office, and nobody noticed the output was garbage until two days later.
Cron is great at one thing: fixed intervals. Every hour, every day at 5 AM, every Monday. What it has no concept of is a holiday, a blackout window, or "the first working day after a long weekend." Those aren't interval problems. They're calendar problems, and cron was never built to answer them.
What a calendar actually buys you
The fix isn't a smarter cron expression, there isn't one. It's separating "when does this job normally run" from "is today actually a valid day to run it," and letting the second question filter the first. That's what calendar scheduling does: a calendar sits on top of a schedule and decides, date by date, whether the job fires.
There are a few shapes this takes, depending on who's setting the rule and how complex it needs to be.
Pick the dates by hand. For a monthly review or a quarterly task, someone just clicks the valid days on a visual calendar, or applies a quick pattern like "every weekday" or "every Monday." No code, no logic, just a list of dates that's easy for a non-technical person to manage.
Write the logic. "Every third Friday of the month" or "the first working day after a public holiday" isn't something you pick by hand, it's something you compute. A code-based calendar lets a developer define that rule once instead of manually updating a date list every year.
Combine calendars. Sometimes the rule you actually want is the relationship between two calendars, not either one alone. Working days minus public holidays. The overlap between two teams' on-call windows. Set operations, union, intersection, difference, handle this without hand-maintaining a third list that has to stay in sync with the other two.
Reschedule instead of skip. Some jobs can't just not run on a holiday, they need to run later. A reschedule calendar skips the blackout days and pushes the job out by a defined number of days instead of dropping it entirely, useful for anything that absolutely has to happen, just not today.
Why this matters more than it sounds like it should
The real cost of the Thanksgiving-cron story isn't the one bad run. It's that nobody could say, with confidence, which other jobs had the same blind spot, because the holiday logic, if it existed at all, was scattered across whatever script each team happened to write. A calendar makes that rule explicit and reusable: define it once, attach it to any schedule that needs it, and get a preview of every date the job will actually run before it goes live.
That last part matters more than it seems. Scheduling logic is the kind of thing that's nearly impossible to verify by reading code, you want to see the actual dates, not trust that the expression is right. A snapshot preview turns "this should be correct" into "this is visibly correct," which is a meaningfully different level of confidence before something goes live in production.
If cron has ever run a job on a day it really shouldn't have, Unmeshed's calendar scheduling is built to be the layer that catches it before it happens, not after.
Top comments (0)