Schedules (a job's header button) starts a job on its own, on a recurring day/time pattern -- a named weekday, weekday/weekend, a day-of-month, first/last of month or year, or a plain daily window. Each schedule has its own repeat frequency inside its window, a cap on how many times it can fire per period, and what to do if a run overruns its expected length (warn, or kill it) or if the window closes before it got a chance to fire (skip it, or still run within a grace period).

Several schedules on one job

A job can have any number of active schedules at once. When more than one could plausibly fire at the same moment, the more specific day-type always wins outright (a real calendar date beats a named weekday, which beats a weekday/weekend bucket, which beats "every day") -- and among schedules of the same specificity, the one with the narrower time window wins. This lets you run something every 30 minutes all day, and separately every 5 minutes during a specific afternoon window, without the two fighting each other.

Run on startup

A schedule can also be marked to fire once, unconditionally, the first time the Worker service evaluates schedules after it (re)starts -- on its own, or alongside a real recurring pattern. This is what catches a window that was missed entirely because Worker was down for the whole thing (a patch, a reboot) rather than just briefly busy.

Schedules vs. a file-watch Start trigger

A job can be started by a schedule or a file-watch Start gate, never both -- the Schedules button (and the job detail page's inline Add Schedule button) disables itself with an explanatory tooltip the moment a Start-scope gate is already attached, since both answer the same question ("what makes this job start on its own") and letting them coexist would just mean two competing answers.

See also: Glossary for related terms.