Alright, fellow migration veterans, I've hit another one of those calendar quirks that always seems to break during a platform switch. 😅
I'm setting up a monthly financial roll-up in Flux, pulling from our old on-prem data warehouse into the new cloud lakehouse. The business requirement is classic: run the workflow on the *last weekday* of each month. Not just the last calendar day—because if the 31st is a Saturday, we need it to run on the Friday 30th. We used to handle this with a cron hack on our old scheduler, but I want to do it natively in Flux's scheduler.
I've been poking at the cron syntax in the schedule config, but I'm not seeing a straightforward way to express "last weekday." I could do something like `0 0 28-31 * *` and then add logic to skip weekends, but that feels clunky and would run multiple times at month-end.
Has anyone else wrestled with this? What's the cleanest pattern?
* Did you build a filter into the workflow itself to check the day-of-week and date, then exit early if it's not the correct day?
* Or is there a smarter cron expression I'm missing?
* Or maybe you solved it by triggering the workflow from a separate service that calculates the date?
I'm especially curious about any pitfalls—like timezone handling or February edge cases—that you ran into. These are the details that always cause the midnight pager alerts after a migration.
Ah, the "last business day" cron puzzle - I've wrestled with that exact beast across GitHub Actions and GitLab CI. Your instinct about `28-31 * *` being clunky is spot on, because yeah, you'd get multiple executions and need internal logic.
For Flux's scheduler, I don't think there's a single cron expression that handles it. The cleanest pattern I've settled on is a two-step approach:
1. Schedule the job to run daily in that end-of-month window (e.g., `0 0 28-31 * *`).
2. Make the **first step** of your workflow a quick date calculation to confirm it's actually the last weekday. If it's not, fail fast and exit cleanly.
It feels a bit like shifting the hack from the scheduler to the script, but it's more explicit and portable. You could bake that check into a shared script or a small Docker container your first step calls. It also logs *why* it skipped, which is handy.
Have you considered having a tiny, separate cron job that just calculates the correct date each month and then triggers your main Flux pipeline via API? Adds complexity, but keeps your pipeline logic pure.
Pipeline Pilot
The daily schedule with an internal check is the standard answer, but it's a workaround that just moves the complexity. It also means your workflow is firing and failing 2-3 times a month, which can clutter logs and confuse monitoring alerts.
Better to push the date logic upstream. Have a lightweight cron job that runs weekly, calculates the next last weekday, and then triggers the Flux workflow via its API. Keeps the scheduler config simple and the workflow logic clean.
always check the last 6 months of reviews