What does the pipeline cron schedule `*/15 9-17 * * 1-5` actually fire on?

## Field layout The classic five-field expression is positional: ```text */15 9-17 * * 1-5 | | | | | | | | | +-- day of week (0-6, Sunday is usually 0) | | | +-------- month (1-12) | | +------------- day of month (1-31) | +------------------- hour (0-23) +--------------------------- minute (0-59) ``` Each field accepts a wildcard `*`, a single value (`30`), a list (`0,30`), an inclusive range (`9-17`), or a step (`*/15`, or `9-17/2` for every second hour in that range). A firing happens at every minute where **all** fields match. So `*/15 9-17 * * 1-5` matches minutes 0, 15, 30 and 45 of every hour from 09 to 17 inclusive, on Monday through Friday: nine hours times four firings equals 36 per weekday, first at 09:00, last at 17:45. ## The three details that trip people up **Ranges are inclusive at both ends.** `9-17` is nine hours, not eight. People expecting the last run at 17:00 are off by 45 minutes and four runs. **Steps are anchored to the field, not to the deploy.** `*/15` means "minutes divisible by 15", so the schedule is aligned to the clock. Deploying at 09:07 does not produce firings at :07, :22, :37. This is exactly what you want for data pipelines, because it makes the window boundaries land on round numbers. **Day-of-month and day-of-week interact oddly.** When *both* fields are restricted (neither is `*`), the traditional Unix behaviour is to treat them as OR rather than AND, so `0 0 1 * 1` fires on the 1st of the month *and* on every Monday. Implementations differ here; if you need "the first Monday", check your scheduler's documentation rather than assuming, and prefer expressing it in code. ## What cron cannot express Cron is a *pattern match on a calendar clock*, not an interval timer. That means several ordinary-sounding requirements are simply not expressible: - **Any cadence that does not divide its unit evenly.** "Every 90 minutes" has no cron expression, because the firing times drift across hours. `0 */6 * * *` works (00:00, 06:00, 12:00, 18:00) because six divides 24; `0 */7 * * *` does not do what people expect — it fires at 00, 07, 14 and 21, then restarts the pattern at midnight, leaving a three-hour gap. - **"N units after the previous run finished."** Cron does not know when the last run finished, or whether it is still running. - **Business-calendar rules** like "the last business day of the month" or "skip public holidays", which need real logic. This is why orchestrators usually offer a second style of schedule alongside cron — a fixed **interval** such as every 30 minutes or every 6 hours, measured from an anchor point — and, for anything genuinely irregular, a programmatic schedule you write yourself. ## Timezone A cron string on its own has no timezone; it inherits whatever the scheduler is configured to use. Two consequences matter. First, `0 9 * * 1-5` means 09:00 in that configured zone, which may not be any stakeholder's local morning. Second, if the configured zone observes daylight saving, some wall-clock times will be skipped or repeated twice a year, and a nominal 24-hour day becomes 23 or 25 hours. Defining schedules in UTC removes that class of problem at the cost of the schedule drifting relative to local business hours. ## Reading an unfamiliar expression under pressure Work left to right and say each field out loud: "minutes zero fifteen thirty forty-five, hours nine through seventeen, any day of month, any month, Monday through Friday." Then sanity-check the count — 4 per hour, 9 hours, 5 days a week — and state the first and last firing time. Naming the boundary cases is what separates a confident answer from a guess.