Cron expression for every 3 hours
Every 3 hours.
Next 10 runs
In Cron, worked out in your browser from the current time.
At a glance
- Runs
- 8 a day
- Gap between runs
- Always 3 hours
- Expressible in
- All six dialects
- Clock changes
- Affected in Helsinki
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 */3 * * * /path/to/command- Runs in the machine’s time zone. cronie also reads a
CRON_TZ=line above the entry; other crons may not.
aws events put-rule --name every-3-hours --schedule-expression "cron(0 0/3 * * ? *)"- 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. rate(3 hours)is the interval alternative. It counts from when the rule is created, so runs will not line up with the clock the way the cron form does.- Scheduled rules always run in UTC. For local times, create it in EventBridge Scheduler with
--schedule-expression-timezone.
CronScheduleBuilder.cronSchedule("0 0 0/3 * * ?")- The leading
0is 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.
schedule: "0 */3 * * *"- Without
timeZoneunderspec, these times are in the kube-controller-manager’s zone. ACRON_TZ=prefix in the schedule fails validation.
- cron: '0 */3 * * *'- 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:besidecron, with an IANA name.
[TimerTrigger("0 0 */3 * * *")]- Six fields with seconds first, so the leading
0fires at the top of the minute. - UTC unless the app sets
WEBSITE_TIME_ZONE, which Linux Consumption and Flex Consumption plans do not support.
About this schedule
Eight runs a day at 00:00, 03:00, 06:00, 09:00, 12:00, 15:00, 18:00 and 21:00. Three divides 24 evenly, so the last run of the day is three hours before the next midnight run.
Clock changes
Worked out by running each dialect’s engine through Helsinki’s clock changes.
| Dialect | Clocks go forward (03:00 becomes 04:00) | Clocks go back (04:00 becomes 03:00) |
|---|---|---|
| Cron | 03:00 doesn’t exist that day, so it’s skipped | 03:00 happens twice, and it runs both times |
| EventBridge Scheduler | 03:00 doesn’t exist that day, so it’s skipped | 03:00 happens twice, and it runs once, in the first pass |
| Quartz | 03:00 doesn’t exist that day, so it’s skipped | 03:00 happens twice, and it runs once, in the second pass |
| Kubernetes | 03:00 doesn’t exist that day, so it’s skipped | 03:00 happens twice, and it runs both times |
| GitHub | 03:00 doesn’t exist that day, so it runs at 04:00 | 03:00 happens twice. GitHub doesn’t document whether it repeats; shown once here |
| Azure | 03:00 doesn’t exist that day, so it runs at 04:00 | 03:00 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 3 hours?
0 */3 * * *in standard cron, Kubernetes and GitHub Actions. The other dialects differ:0 0/3 * * ? *in EventBridge;0 0 0/3 * * ?in Quartz;0 0 */3 * * *in Azure.- Does
0 */3 * * *count from when the job is created? - No. It matches clock times: 00:00, 03:00 and so on, whenever it was created. EventBridge’s
rate()form is the one that counts from creation instead. - What happens to this schedule when the clocks change?
- It depends on the scheduler. When clocks go forward in Helsinki (03:00 becomes 04:00): Cron, EventBridge, Quartz and Kubernetes: 03:00 doesn’t exist that day, so it’s skipped. GitHub and Azure: 03:00 doesn’t exist that day, so it runs at 04: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.timeZoneor the controller manager’s zone, Quartz the JVM’s zone orinTimeZone, and cron the machine’s zone orCRON_TZ.