Cron Atlas

Cron expression for every hour at minute 30

30 * * * *
minute30
hourevery hour
day of monthevery day
monthevery month
day of weekany weekday

At minute 30 of every hour.

Next 10 runs

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

At a glance

Runs
24 a day
Gap between runs
Always 1 hour
Expressible in
All six dialects
Clock changes
Affected in New York, London, Berlin, Helsinki, 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.

Cron
30 * * * *
30 * * * * /path/to/command
Exact
EventBridge
30 * * * ? *
aws events put-rule --name every-hour-at-30 --schedule-expression "cron(30 * * * ? *)"
  • 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.
Exact
Quartz
0 30 * * * ?
CronScheduleBuilder.cronSchedule("0 30 * * * ?")
  • 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.
Exact
Kubernetes
30 * * * *
schedule: "30 * * * *"
  • If a Job can run longer than 1 hour, the next one starts alongside it by default. concurrencyPolicy: Forbid skips the new run instead, and Replace stops the old one.
  • The controller stops starting a CronJob that has missed more than 100 schedules. At this rate that is 100 hours of downtime. startingDeadlineSeconds limits how far back it counts.
Exact
GitHub
30 * * * *
- cron: '30 * * * *'
Exact
Azure
0 30 * * * *
[TimerTrigger("0 30 * * * *")]
  • Six fields with seconds first, so the leading 0 fires at the top of the minute.
Exact

About this schedule

Minute 30 of every hour, so 00:30, 01:30 and on through 23:30. Moving an hourly job off :00 is GitHub’s own advice for avoiding delays, and it spreads load on any shared scheduler.

Clock changes

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

DialectClocks go forward (02:00 becomes 03:00)Clocks go back (02:00 becomes 01:00)
Cron02:30 doesn’t exist that day, so it’s skipped01:30 happens twice, and it runs both times
EventBridge Scheduler02:30 doesn’t exist that day, so it’s skipped01:30 happens twice, and it runs once, in the first pass
Quartz02:30 doesn’t exist that day, so it’s skipped01:30 happens twice, and it runs once, in the second pass
Kubernetes02:30 doesn’t exist that day, so it’s skipped01:30 happens twice, and it runs both times
GitHub02:30 doesn’t exist that day, so it runs at 03:0001:30 happens twice. GitHub doesn’t document whether it repeats; shown once here
Azure02:30 doesn’t exist that day, so it’s skipped01:30 happens twice, and it runs both times

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 hour at minute 30?
30 * * * * in standard cron, Kubernetes and GitHub Actions. The other dialects differ: 30 * * * ? * in EventBridge; 0 30 * * * ? in Quartz; 0 30 * * * * 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, Kubernetes and Azure: 02:30 doesn’t exist that day, so it’s skipped. GitHub: 02:30 doesn’t exist that day, so it runs at 03:00. The table on this page also covers the autumn change.

More schedules