More Dynamic Cronjobs
Key topics
The quest for more dynamic cronjobs has sparked a lively discussion around handling complex scheduling needs, particularly when it comes to accounting for holidays and non-business days. Some commenters pointed out that running conditional commands within cron is not new, while others shared their own approaches to managing holiday dates, such as maintaining a programmatically accessible list or using libraries like Ruby's business_time. A surprising takeaway is that many companies have developed custom solutions to handle holiday dates, with some even building dedicated systems to emit events when holiday dates change. As one commenter noted, using a simple holidays.json file has become a de facto standard for handling these edge cases.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
52m
Peak period
7
9-12h
Avg / period
2.8
Based on 31 loaded comments
Key moments
- 01Story posted
Dec 27, 2025 at 1:10 AM EST
16 days ago
Step 01 - 02First comment
Dec 27, 2025 at 2:02 AM EST
52m after posting
Step 02 - 03Peak activity
7 comments in 9-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 29, 2025 at 12:31 AM EST
14 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I work at a company with different holidays in certain countries, which would complicate things, and require something more structured than an implementing dates. But having that accessible could be useful.
Has anyone tackled that, or come across a solution?
https://www.gov.uk/bank-holidays.json
This happens surprisingly often, given that religious dates change and there are holidays/closures for storms in some regions.
I think the systemd timer would give you the benefit here as you can write the time in varying formats. Timezones, UTC, local, or whatever. That should give you the structure you need, if I'm understanding your problem correctly.
While systemd has more boilerplate than cron I think it has a lot of advantages that make it worth it. Best to just have a skeleton of these jobs (I keep some in my dotfiles) and then you have it. Or have the LLM write it (ironically one of the few instances I'll advocate for letting the AI write the code). You can do everything in the article and so much more.
https://man.archlinux.org/man/systemd.time.7
It parses the file using jq and compares its entries with the current time according to GNU date. At the root is the names of the jobs. Each job has its own list of holidays. Each of these holiday items in the job's respective list has keys for the display name of the holiday, the formatted date to compare to, and in a few cases the ISO day-of-week and a string containing a modulo arithmetic function (e.g. don't run the friday before Christmas, etc.). Sorry, yes that means I call eval and yes that means some of these are repeated in the same file under the arrays for the other jobs.
I don't know if that helps. I know it's hacky, but I don't think there's a nice way to handle things like "second monday after 4th of july, but if the 4th also happens to be monday then it should instead be the second tuesday".
What you do instead, is you schedule the cronjob for the most generic case, e.g. each day. And if it does not need to run 3 days before holidays with crescent moon when wind is blowing from the south, it is just the part of business logic of the process, which you write in the any proper programming language that you prefer (or that the system is written in anyway).
Now, how do you manage the list itself depends on the details and I've done all sorts dirty things that one probably shouldn't do (cutting corners), but in the most flexible case it is just some CRUD-type page in your back-office system, with a real UI, and there is a person (usually in the bookkeeping department of the company) who has it among his responsibilities to maintain the schedule. You store it in some proper SQL database and cache it aggressively, so the the myriads of cronjobs don't bother it more than necessary.
The next sleep interval would be calculated probably as as t = -\lambda \ln(U) (where U is a uniform random variable). This way you ensure that the probability of the job firing in the next 10 seconds is the same whether the last job finished an hour ago or just five seconds ago. But \lambda remains the average amount of time between jobs.
It’s compelling to me because it solves thundering herd problems at the architectural level, and also because it simply seems like a lot of fun to have to code very defensively against such chaos. Switching back to a deterministic schedule after surviving such chaos probably leads to a much more robust system overall.
Nit: you’re not relying on the memoryless property here but just plain old independent sampling. You’re right that memorylessness means that the elapsed time since the last job provides no information on when the job fires next, but this is orthogonal to the independence of the sleep intervals.
If you're thinking about using NFS, why would you want to distribute your locks across other machines?
Sometimes certain containerized processes need to run according to a schedule, but maintainers also need a way to run them manually without the scheduled processing starting concurrently. A shared FS seems like the ”simplest thing that could possibly work” distribution method for such locks, but unfortunately not all cloud storage volumes are strongly consistent, even to the same user, and may take several ms for the lock to take hold.
FWIW, it’s not NFS.
https://avilpage.com/2024/08/guide-systemd-timer-cronjob.htm...
These days I tend to use systemd timers on Linux though. Despite my love/hate relationship with systemd, timers and service files are really nice.
[1]https://metacpan.org/pod/App::Cronjob https://metacpan.org/dist/App-Cronjob/view/bin/cronjob