Cron Schedule Explainer

Cron line

Five fields: minute, hour, day of month, month, day of week. Shortcuts such as @daily work too.

Minute: 30at minute 30
Hour: 9at hour 9
Day of month: *every day
Month: *every month
Day of week: 1-5Monday through Friday

At 09:30, Monday through Friday, server time (UTC)

Start from a preset

The job runs on

Next five runs
UTC	Dhaka (UTC+6)

`0 2 * * *` on a UTC server fires at 8 in the morning in Dhaka

02:00UTC, on the server

08:00Dhaka, in the middle of the working day

A backup job is set to 0 2 * * * on a server that runs on UTC, so it fires at 8 in the morning in Dhaka, in the middle of the working day.

Cron lines are short and easy to misread, and the mistake usually shows up as a slow site or a missed report. Seeing the schedule in words and in local time catches it before it runs.

What the fields accept

Values a cron field accepts, with an example of how each one reads back
Write	It is	Example	Reads back as
`*`	Every value in the field	`*` in Minute	every minute
`1-5`	A range	`1-5` in Day of week	Monday through Friday
`*/15`	A step	`*/15` in Minute	every 15 minutes
`1,15`	A list	`1,15` in Day of month	1st and 15th
`MON` to `SUN`	Day names	`SAT,SUN` in Day of week	Sunday and Saturday
`JAN` to `DEC`	Month names	`JAN-MAR` in Month	January through March
`@daily`	A shortcut for the whole line. `@hourly`, `@weekly`, `@monthly` and `@yearly` work too	`@daily` on its own	At 00:00, every day

Standard five-field cron. When both day of month and day of week are restricted, a run happens when either one matches.
Values out of range, the wrong number of fields and unknown names are flagged with the field they are in.
Runs in your browser. Nothing is saved or sent anywhere.

Who it is for

Developers and DevOps engineers

Check a schedule before it goes into a crontab, a CI job or a Kubernetes CronJob.

Teams running automations

Confirm when reports, syncs and backups really run in local time.