Schedule Rules

Day

The two month end rules reposition a run: they move it to a day the CRON could not name. Working Day does the opposite - it moves nothing and instead filters out the runs that fall badly. Which of the two you want decides everything else on this page, so it is worth being clear which you are reaching for.

A month end rule changes only the date. The time of day always comes from the CRON, so 30 6 1 * * with Last working day of month runs at 06:30 on the last working day. Only one rule can apply, so ticking one unticks any other. Leaving them all unticked keeps the dates the CRON gave, which is how every Job behaved before this setting existed.

Runs on schedule in

The second branch of the picker is a small tree of the environment kinds a Job runs on its schedule in:

All environments is ticked by default, which is how every Job behaved before this setting existed, and every existing Job is left that way by the upgrade. Ticking it ticks everything below, unticking it clears everything, and it unticks itself as soon as you untick any one child.

All environments really does mean all. A Job left on the default picks up new kinds of environment automatically - if a further environment definition is ever added, Jobs nobody has narrowed will run there without being touched. That is why a Job records the environments it is kept out of rather than the ones it runs in: a list of what it runs in would be a snapshot of the environments that existed the day it was written.

Untick all three and the Job never runs on its own schedule anywhere; the picker warns you when that happens.

Environments are matched on their definition, not their name or id, so the setting survives deployment: a Job restricted to Production keeps that restriction when promoted, instead of needing its schedule unpicked by hand in each environment. In an environment that is not selected the Job shows no next scheduled run, and the picker says so rather than leaving an unexplained blank.

A Job excluded here is only excluded from its own schedule. It can still be nested as a task in another Job, triggered through the Scheduler Web API, or started with Run Now.

Recipes

A month end rule decides which day of the month, and the CRON decides which months and at what time. Working Day leaves the CRON's own dates alone and only drops the ones that fall badly. Change the 4 to run at a different hour.

For the last one, also untick every environment except Production.

Things to watch

• Working Day drops runs, it does not defer them. A run the calendar rejects is gone; the next one is whenever the CRON next fires on a working day. On a sparse CRON that can mean skipping a month, a quarter, or everything.

• A month with no working day at its end is passed over. If the calendar shows an unbroken closure of more than a month running up to month end, that month is skipped and the next one the CRON names is used. If nothing within two years works, the Job is left unscheduled and an error is logged rather than the scheduler searching forever.

• Everything in the picker deploys with the Job. The deploy preview flags a change to any of it just as it flags a change to the CRON. Each environment reads its own dim_date, so a Test warehouse without holidays loaded will schedule differently to Production.