In GitHub Actions, what are the rules for a schedule: cron trigger?

## The syntax ``` on: schedule: - cron: '17 3 * * 1-5' - cron: '0 */6 * * *' ``` `schedule` is a **list**, so a workflow can carry several cron expressions. Each entry is a standard five-field POSIX cron string: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12 or names), day-of-week (0–6 or names, where both 0 and 7 are Sunday). The operators are `*` (any), `,` (list), `-` (range) and `/` (step). The value must be quoted, because a bare `*` starts a YAML alias and will not parse. There is no `timezone` key. GitHub Actions evaluates every cron expression in **UTC**, full stop. A job you want at 09:00 in a European office is `0 8 * * *` in winter and `0 7 * * *` in summer — pick one and accept the hour of drift, or schedule twice and gate on the date, or simply schedule at a time where the shift does not matter. Candidates who claim they set a timezone are remembering a different CI system. ## Interval floor The shortest interval GitHub honours is **five minutes**. `*/1 * * * *` does not give you a run every minute; it is throttled. If you need sub-five-minute reactions you are outside what the scheduler is for — use an external trigger that dispatches the workflow, or a long-running process outside Actions. ## Which code runs This is the mechanic most people get wrong. A scheduled run has no ref you can choose: GitHub runs the workflow **as defined on the default branch**, against the **latest commit of the default branch**. Consequences: - Adding a `schedule:` block on a feature branch produces nothing until it is merged. - Editing the cron on a feature branch changes nothing about the live schedule. - `github.ref` inside a scheduled run is the default branch's ref. - You cannot schedule a job "for the release branch" through the trigger; you would check that branch out explicitly inside the job, or use `workflow_dispatch` for ref-specific runs. `schedule` also accepts no `branches`, `tags` or `paths` filters — there is no ref or diff to filter on. ## Timing is best-effort A scheduled workflow is queued when capacity allows, not at a guaranteed instant. Delays are common at the top of the hour, when a very large share of the world's crons fire simultaneously; a run scheduled for `0 * * * *` may start noticeably late, and under heavy load a scheduled run can be dropped rather than merely delayed. Two practical rules follow: never write a workflow that assumes exact start time (compute windows from an actual timestamp, not from the cron), and offset your minute — `17 3 * * *` rather than `0 3 * * *` — which measurably improves punctuality by avoiding the crowd. ## Automatic disabling GitHub disables scheduled workflows in a **public** repository after **60 days** with no repository activity, to stop abandoned repos consuming shared capacity. The Actions tab shows the workflow as disabled with a button to re-enable it; a commit or other activity also revives it. Separately, when a public repository is **forked**, scheduled workflows are disabled in the fork by default — this is why a fork does not start emailing its owner about your nightly job. In a private repository the 60-day rule does not apply the same way, but the practical lesson stands: a silent nightly job is one you should monitor, because "it stopped running" is a failure mode that produces no failure notification. ## Guarding forks and pairing with dispatch Two idioms belong on nearly every scheduled workflow. First, a fork guard, so a fork that re-enables Actions does not run your maintenance job against your assumptions: ``` jobs: nightly: if: github.repository == 'acme/service' ``` Second, a companion `workflow_dispatch:` under the same `on:` block, so you can reproduce a nightly failure immediately instead of waiting a day. Both are cheap and both come up in interviews as "what would you add to this file". ## What schedule is good for Nightly integration suites too slow for a pull request, dependency-freshness or licence audits, cache warm-ups, stale-issue sweeps, expiring-credential checks, and reporting. What it is *not* good for: anything requiring exact timing, anything needing sub-five-minute frequency, and anything that must run against a non-default branch. Recognising those three boundaries is the substance of the question.