Cron expression explainer and next runs

Common schedules

Cron and daylight saving time

On the spring change day an hour of wall-clock time never happens; in central Europe 02:00 to 02:59 is skipped. On the autumn change day an hour happens twice. A job scheduled inside that hour is the one that surprises you, and each scheduler resolves it its own way:

The safe choice for anything daily is a time outside 01:00 to 03:59, or a timezone without daylight saving such as UTC. The sources for each row are in the questions below.

Cron timezone on each platform

# Kubernetes
spec:
  schedule: "30 2 * * *"
  timeZone: "Europe/Berlin"

# GitHub Actions
on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "America/New_York"

Cron syntax

* means every value, 1-5 a range, 1,15 a list and */10 every tenth value. ? means the same as *. L, W, # and a sixth seconds field are Quartz and Spring syntax, not standard cron.

Questions people ask

• How does cron handle daylight saving time?

  Vixie cron, cronie and Debian's cron treat a clock change of less than three hours specially, but only for jobs that run at a fixed time. When the clock moves forward, a fixed-time job that would have run in the skipped hour runs soon after the change. When it moves back, a fixed-time job in the repeated hour is not run a second time. A job with * in its minute or hour field, or @hourly, follows the clock: its runs in the skipped hour do not happen and it runs in both passes of the repeated hour. Source: the cron(8) manual pages of Debian and cronie.

• How does a Kubernetes CronJob handle daylight saving time?

  The Kubernetes documentation does not describe it. The CronJob controller computes schedule times with the robfig/cron v3 library in the zone set by .spec.timeZone, and that library's documentation warns that jobs scheduled during daylight-savings leap-ahead transitions will not be run. Its next-time calculation also returns both occurrences of a repeated wall-clock time, so a fixed time in the repeated hour can run twice. This page shows that behaviour in its Kubernetes mode.

• What timezone does a Kubernetes CronJob use?

  Without .spec.timeZone, the kube-controller-manager interprets the schedule in its own local time zone. Set .spec.timeZone to an IANA name such as Etc/UTC or Europe/Berlin; the field is stable since Kubernetes v1.27. Kubernetes rejects TZ or CRON_TZ inside .spec.schedule with a validation error. Source: the Kubernetes CronJob documentation.

• Do GitHub Actions schedules follow daylight saving time?

  Scheduled workflows run in UTC by default, and UTC has no daylight saving. A schedule can set an optional timezone key to an IANA name. For a timezone that observes daylight saving, GitHub documents that during the spring-forward change, runs in the skipped hour advance to the next valid time, so 2:30 AM becomes 3:00 AM. GitHub does not document the repeated hour in the autumn. The shortest interval is once every 5 minutes, and runs can be delayed at busy times such as the start of every hour. Source: the GitHub Actions documentation for the schedule event.

• What timezone does Linux cron use?

  The cron daemon uses the system timezone; Debian's cron reads it from /etc/timezone and handles all jobs in a single timezone. cronie, on Fedora and RHEL, also accepts a CRON_TZ= line that sets the timezone for the crontab it appears in. Pick the server's timezone in the tool above to see when a job really runs.

• What happens when both day of month and day of week are set?

  If both fields are restricted, the job runs when either one matches, not only when both do: 0 0 1,15 * 5 runs on the 1st, on the 15th and on every Friday. In Vixie cron a field that starts with * counts as unrestricted for this rule even with a step, so 0 0 */2 * 1 runs only on Mondays that fall on an odd day. Kubernetes treats */2 as restricted and runs on every odd day and every Monday.

• Is 7 Sunday in cron?

  In Linux cron, yes: day of week takes 0 to 7, and both 0 and 7 are Sunday (Debian crontab(5)). Kubernetes documents day of week as 0 to 6 and GitHub Actions documents 0 to 6 or SUN to SAT, so use 0 for Sunday there.

• Is anything I type here sent to LastPing?

  No. The explanation and the next runs are computed in your browser, and nothing is stored. Timezone rules come from your browser's own timezone data, which can differ from a server's for rare zones or after a recent rule change.