If checked, cron (timer) triggered builds of this job are refused while Enable run control is on; unchecked, they pass this switch. It applies whether or not Require approval to run is checked.

This switch is not what puts a job into service. A cron run starts only if the job is activated (an approved activation request, made from the job page) and this switch is off. Unchecking it on a job that is not activated changes nothing: the run is still refused, for the activation. A job created while run control is on starts not activated and with this switch checked, so a new scheduled job needs both: request its activation, then uncheck this switch. Jobs that already existed when run control was turned on were recorded as activated.

A value supplied when the job was created does not survive the creation lock: a blockTimer=false in a config.xml POST, a CLI create-job, a Job DSL seed or the job this one was copied from is overwritten. A later run of the same seed is an update rather than a creation and does apply it.

If this job's cron did not fire, read this first. A refused timer run has nobody to show a message to, but it leaves traces:

• the job page — it says whether the job is activated, and, while this switch is checked, shows a notice naming Block cron (timer) triggers;
• the change history — a refused timer run writes a TRIGGER_BLOCKED change record naming the job, the cause kind and what blocked it (the activation or this switch), at most one per job and cause kind per hour, listed under Change Records and History and in changes.csv; a cron that never fired writes nothing;
• the controller log — a "Blocked timer-triggered run of job" line, at most once an hour per job (repeats are logged at FINE).

Unchecking this switch is a recorded configuration change and, with change control on, needs a permission window.