Weekday Office Hours Cron – Free, Online, Private
0 9-17 * * 1-5 runs at minute 0 of each hour from 09:00 through 17:00, Monday to Friday. Plain English: Every hour, between 09:00 and 17:00, Monday through Friday
The next runs appear when the expression parses.
0 9-17 * * 1-5 /usr/local/bin/job
on:
schedule:
- cron: "0 9-17 * * 1-5"
apiVersion: batch/v1
kind: CronJob
metadata:
name: job
spec:
schedule: "0 9-17 * * 1-5"
timeZone: "Etc/UTC"
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: job
image: busybox:1.36
args: ["echo", "job"]
The expression
0 9-17 * * 1-5 is a five-field cron expression: minute, hour, day of month, month, day of week. There is no seconds field and no year field. Every hour, between 09:00 and 17:00, Monday through Friday The next five run times on this page are computed in your browser with the same expression, in UTC, so a reload later in the hour shows a later list. Edit the box if you want to nudge a field and watch the list change, or open the line in the cron parser.
What each field is doing
The minute field is the single value 0. No other value in the 0–59 range matches. The hour field is the inclusive range 9-17, from 9 through 17, inside the 0–23 range. Values outside the range do not match. The day-of-month field is an asterisk, so every value in the 1–31 range is allowed. This field is not what limits the schedule. The month field is an asterisk, so every value in the 1–12 range is allowed. This field is not what limits the schedule. The day-of-week field is the inclusive range 1-5, from 1 through 5, inside the 0–6, Sunday as 0 or 7 range. Values outside the range do not match.
When the day-of-month and day-of-week fields are both something other than *, many cron implementations run the job if either field matches. This preset leaves at least one of those two fields as *, so you do not have to resolve that rule to predict it. Names such as MON and JAN are readable and widely accepted. The snippets use numbers so a strict parser does not have to know the names.
Why this schedule
Office hours are a range on the hour and a range on the weekday. This fires nine times a weekday: 09:00, 10:00, and so on through 17:00. It does not fire at 08:00 or at 18:00. It does not fire on Saturday. It is the expression to use when an hourly check is useful only while people are at work.
Pinging a support queue, refreshing a dashboard that nobody watches at night, and nudging a human about a stuck review fit inside the range. A backup should not be limited to office hours unless you enjoy restoring from Friday.
Where it goes wrong
The end of a range is inclusive. 9-17 includes 17. People who want the last run at 16:00 should write 9-16. The day-of-month field is still *. Holidays are not excluded. GitHub Actions interprets the hours in UTC, so 'office hours' in the workflow file are office hours only for a team that works UTC.
A sixth field is the seconds field used by Quartz, some Spring apps, and some Kubernetes setups that are not the classic CronJob schedule. Classic crontab, GitHub Actions, and the schedule field of a batch/v1 CronJob are five fields. If you paste a six-field line into those systems, the extra token shifts every field one place to the left and the job runs on a different day. L, W, and the # 'nth weekday' modifier are real in some daemons and rejected or reinterpreted in others. They are not used on this page. The English description and the next runs both refuse to guess at a token the calculator does not share with every target.
Crontab, GitHub Actions, and Kubernetes
GitHub Actions accepts this cadence. The schedule is UTC, it can start late when the service is busy, and it is dropped if the repository has had no activity for sixty days. The workflow file only needs the expression. It does not need a seconds field.
A user crontab does not include the username. A system crontab, the kind in /etc/crontab, inserts the user between the expression and the command. The line below is the user form. Kubernetes CronJob has used spec.timeZone since 1.27. The manifest sets it to Etc/UTC so the schedule matches the next-run list. Remove the field on a cluster older than that, and know that the schedule then uses the controller's zone.
crontab0 9-17 * * 1-5 /usr/local/bin/job
GitHub Actionson:
schedule:
- cron: "0 9-17 * * 1-5"
Kubernetes CronJobapiVersion: batch/v1
kind: CronJob
metadata:
name: weekdays-hourly
spec:
schedule: "0 9-17 * * 1-5"
timeZone: "Etc/UTC"
jobTemplate:
spec:
template:
spec:
containers:
- name: job
image: busybox:1.36
args: ["echo", "weekdays-hourly"]
restartPolicy: OnFailure
- Keep the command idempotent. Cron does not remember a failure and it does not skip a run that is already in progress.
- Write the timezone next to the expression. UTC in the file and local time in the ticket are how a job fires eight hours early.
- Offset the minute if several jobs would otherwise start at once.
Frequently asked questions
What does 0 9-17 * * 1-5 mean?
Weekday Office Hours Cron is the five-field expression 0 9-17 * * 1-5. Every hour, between 09:00 and 17:00, Monday through Friday
Does 0 9-17 * * 1-5 include a seconds field?
No. Weekday Office Hours Cron (0 9-17 * * 1-5) is minute, hour, day of month, month, and day of week. Add a seconds field only if the scheduler you are configuring documents six fields, and do not paste that six-field line into a five-field crontab.
Which timezone are the next runs of 0 9-17 * * 1-5 shown in?
UTC. The next five times for Weekday Office Hours Cron are computed from 0 9-17 * * 1-5 in UTC. GitHub Actions schedules are UTC. A server crontab uses the server's zone unless you set one. The Kubernetes snippet on this page sets timeZone to Etc/UTC.
Can I edit 0 9-17 * * 1-5 on this page?
Yes. The box starts as 0 9-17 * * 1-5, the Weekday Office Hours Cron preset, and recomputes the English sentence and the next five UTC runs as you type. The cron parser and the cron builder open the same kind of five-field expression.