Cron Atlas

Cron expression for every hour during business hours

0 9-17 * * 1-5
minute0
hour9–17
day of monthevery day
monthevery month
day of weekMon–Fri

On the hour from 09:00 through 17:00, Monday through Friday.

Next 10 runs

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

At a glance

Runs
45 a week
Gap between runs
1 hour to 64 hours
Expressible in
All six dialects
Clock changes
No effect in the zones checked

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
0 9-17 * * 1-5
0 9-17 * * 1-5 /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
EventBridge
0 9-17 ? * MON-FRI *
aws events put-rule --name business-hours-hourly --schedule-expression "cron(0 9-17 ? * MON-FRI *)"
  • Wrap it in cron(…). Day of week is set (MON-FRI), so day of month has to be ?. The final * is the required year field.
  • In numbers MON-FRI is 2-6, because Sunday is 1 here. Unix cron’s numbers would be off by one.
  • Scheduled rules always run in UTC. For local times, create it in EventBridge Scheduler with --schedule-expression-timezone.
Exact
Quartz
0 0 9-17 ? * MON-FRI
CronScheduleBuilder.cronSchedule("0 0 9-17 ? * MON-FRI")
  • The leading 0 is the seconds field, so it fires at the top of the minute. Day of week is set (MON-FRI), so day of month has to be ?. The optional year is left off.
  • In numbers MON-FRI is 2-6, because Sunday is 1 in Quartz.
  • Uses the JVM’s default zone unless the trigger sets one with inTimeZone.
Exact
Kubernetes
0 9-17 * * 1-5
schedule: "0 9-17 * * 1-5"
  • Without timeZone under spec, these times are in the kube-controller-manager’s zone. A CRON_TZ= prefix in the schedule fails validation.
  • 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
0 9-17 * * 1-5
- cron: '0 9-17 * * 1-5'
  • 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
Azure
0 0 9-17 * * Mon-Fri
[TimerTrigger("0 0 9-17 * * Mon-Fri")]
  • Six fields with seconds first, so the leading 0 fires at the top of the minute.
  • Azure numbers days 0–6 from Sunday, like Unix cron, and matches names by prefix, so keep to three letters.
  • UTC unless the app sets WEBSITE_TIME_ZONE, which Linux Consumption and Flex Consumption plans do not support.
Exact

About this schedule

On the hour from 09:00 to 17:00, Monday to Friday: nine runs a working day. The range is inclusive at both ends, so 17:00 is the last run.

Clock changes

None of these times falls in the hour that clocks skip or repeat in New York, London, Berlin, Helsinki or Sydney, so every dialect runs it normally all year there. Zones that change clocks at other hours can still differ.

Questions

What is the cron expression for every hour during business hours?
0 9-17 * * 1-5 in standard cron, Kubernetes and GitHub Actions. The other dialects differ: 0 9-17 ? * MON-FRI * in EventBridge; 0 0 9-17 ? * MON-FRI in Quartz; 0 0 9-17 * * Mon-Fri in Azure.
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