Cron Atlas

Cron expression for every day at 2am

0 2 * * *
minute0
hour2
day of monthevery day
monthevery month
day of weekany weekday

At 02:00.

Next 10 runs

In Cron, worked out in your browser from the current time.

At a glance

Runs
1 a day
Gap between runs
Always 1 day
Expressible in
All six dialects
Clock changes
Affected in New York, Berlin, Sydney

Open in the tester

In each dialect

Every expression here is generated by the tester’s own engine and checked run for run against the others, so “Exact” means the same clock times in the same zone. Each one links to the tester.

0 2 * * * /path/to/command
  • Runs in the machine’s time zone. cronie also reads a CRON_TZ= line above the entry; other crons may not.
Exact
aws events put-rule --name every-day-at-2am --schedule-expression "cron(0 2 * * ? *)"
  • Wrap it in cron(…). Day of week is ? because day of month already holds *, and a * in both is rejected. The final * is the required year field.
  • Scheduled rules always run in UTC. For local times, create it in EventBridge Scheduler with --schedule-expression-timezone.
Exact
CronScheduleBuilder.cronSchedule("0 0 2 * * ?")
  • The leading 0 is the seconds field, so it fires at the top of the minute. Day of week is ? because day of month already holds *, and a * in both is rejected. The optional year is left off.
  • Uses the JVM’s default zone unless the trigger sets one with inTimeZone.
Exact
schedule: "0 2 * * *"
  • Without timeZone under spec, these times are in the kube-controller-manager’s zone. A CRON_TZ= prefix in the schedule fails validation.
Exact
- cron: '0 2 * * *'
  • GitHub warns that schedules can be delayed at high load, which includes the start of every hour, and that some queued jobs may be dropped. A different minute reduces the risk.
  • Times are UTC unless you add timezone: beside cron, with an IANA name.
Exact
[TimerTrigger("0 0 2 * * *")]
  • Six fields with seconds first, so the leading 0 fires at the top of the minute.
  • UTC unless the app sets WEBSITE_TIME_ZONE, which Linux Consumption and Flex Consumption plans do not support.
Exact

About this schedule

A favourite slot for backups and the worst one for clock changes. In many zones 02:00 does not exist on the spring-forward day, and each scheduler handles that differently: some skip the run, some move it. The table below works it out for each one.

Clock changes

Worked out by running each dialect’s engine through New York’s clock changes; it is affected in Berlin, Sydney too, at their own local hours.

DialectClocks go forward (02:00 becomes 03:00)Clocks go back (02:00 becomes 01:00)
Cron02:00 doesn’t exist that day, so it’s skippedNot affected
EventBridge Scheduler02:00 doesn’t exist that day, so it’s skippedNot affected
Quartz02:00 doesn’t exist that day, so it’s skippedNot affected
Kubernetes02:00 doesn’t exist that day, so it’s skippedNot affected
GitHub02:00 doesn’t exist that day, so it runs at 03:00Not affected
Azure02:00 doesn’t exist that day, so it runs at 03:00Not affected

Cron follows the crontab man page; daemons differ, and cronie catches up skipped fixed-time jobs. EventBridge applies to Scheduler with a time zone; scheduled rules run in UTC and never see a clock change. Quartz is exact for 2.5.2. GitHub documents the forward case only.

Questions

What is the cron expression for every day at 2am?
0 2 * * * in standard cron, Kubernetes and GitHub Actions. The other dialects differ: 0 2 * * ? * in EventBridge; 0 0 2 * * ? in Quartz; 0 0 2 * * * in Azure.
What happens to this schedule when the clocks change?
It depends on the scheduler. When clocks go forward in New York (02:00 becomes 03:00): Cron, EventBridge, Quartz and Kubernetes: 02:00 doesn’t exist that day, so it’s skipped. GitHub and Azure: 02:00 doesn’t exist that day, so it runs at 03:00. The table on this page also covers the autumn change.
Which time zone does it run in?
It depends on the scheduler. GitHub Actions, EventBridge rules and Azure use UTC unless you set a zone (timezone, EventBridge Scheduler’s --schedule-expression-timezone, WEBSITE_TIME_ZONE). Kubernetes uses .spec.timeZone or the controller manager’s zone, Quartz the JVM’s zone or inTimeZone, and cron the machine’s zone or CRON_TZ.

More schedules