Cron expression: every weekday at 09:00
0 9 * * 1-5Runs Monday to Friday at 09:00, skipping Saturday and Sunday.
What each field means
| Field | Value | Meaning |
|---|---|---|
| minute | 0 | minute 0 |
| hour | 9 | hour 9 |
| day of month | * | every day of month |
| month | * | every month |
| day of week | 1-5 | day of week 1 through 5 |
Next runs
Starting from 1 January 2026, 00:00 UTC:
- Thursday 1 Jan 09:00
- Friday 2 Jan 09:00
- Monday 5 Jan 09:00
- Tuesday 6 Jan 09:00
- Wednesday 7 Jan 09:00
- Thursday 8 Jan 09:00
Things to watch
Day-of-week uses 0–6 with Sunday as 0, so Monday to Friday is 1-5. Most implementations also accept MON-FRI.
The same schedule elsewhere
# crontab
0 9 * * 1-5 /usr/local/bin/my-job >> /var/log/my-job.log 2>&1
# GitHub Actions (.github/workflows/job.yml) — always UTC
on:
schedule:
- cron: '0 9 * * 1-5'
# Kubernetes CronJob
spec:
schedule: "0 9 * * 1-5"
# AWS EventBridge — six fields, and ? in one of the day fields
cron(0 9 ? * MON-FRI *)Frequently asked questions
What is the cron expression to run a job every weekday at 09:00?
0 9 * * 1-5
Which time zone does cron use?
The server's local time zone, unless the scheduler says otherwise. GitHub Actions always uses UTC. Kubernetes CronJobs use UTC unless you set spec.timeZone. Running servers in UTC and converting only for display avoids an entire class of daylight-saving bugs.
What happens if the previous run is still going?
Standard cron starts a new one regardless, so long-running jobs can pile up. Wrap the command in flock -n /var/lock/my-job.lock, or set concurrencyPolicy: Forbid on a Kubernetes CronJob.
Why did my cron job not run at all?
The three usual causes: the script is not executable, the command relies on a PATH or environment variable that cron does not set, or output went nowhere because no mail transport is configured. Redirect stdout and stderr to a log file and the reason usually becomes obvious.