Cron Expression Generator

Type each part into its own field box, or start from a preset and edit. The middle column is the plain-English description the tool shows for that expression.

• Field boxes — minute, hour, day of month, month and day of week. A box with an invalid value turns red and the readout explains the problem, for example "60" is out of range (0–59) for minute.
• Description — a plain-English reading of the whole expression, followed by the expression itself and the field order.
• Next scheduled runs — the next six matching times in your browser's local time zone, with the zone abbreviation and a relative time such as "in 2 days, 3 hours". If the list says no upcoming runs were found, the expression can never match, for example 0 0 30 2 * (30 February).
• Visual builder — choose Minute, Hour, Day, Week, Month or Year and fill in the sentence. Editing the fields directly updates the builder on a best-effort basis; complex expressions are easier to edit by hand.

The five fields mean the same thing on these platforms, but the time zone and the surrounding syntax do not.

Linux crontab

# crontab -e  (per-user crontab)
0 9 * * 1-5 /usr/local/bin/daily-report.sh

Jobs run in the system's time zone unless your cron implementation supports something like CRON_TZ (cronie does; check man 5 crontab). In /etc/crontab and /etc/cron.d/* a user name goes between the schedule and the command. A % in the command is treated as a newline unless escaped as \%, and cron runs with a minimal environment, so use absolute paths.

Kubernetes CronJob

spec:
  schedule: "0 9 * * 1-5"
  timeZone: "Etc/UTC"

Without .spec.timeZone, the schedule is interpreted in the time zone of the kube-controller-manager. Put CRON_TZ or TZ in the schedule string and Kubernetes rejects the resource with a validation error — use the timeZone field instead.

GitHub Actions

on:
  schedule:
    - cron: "30 5 * * 1-5"

Scheduled workflows run in UTC by default; GitHub also accepts an optional timezone key with an IANA zone name next to cron . The shortest interval is every 5 minutes, runs can be delayed when load is high (the start of every hour is busiest), schedules only run from the default branch, and @daily -style shortcuts are not supported. In public repositories, scheduled workflows are disabled automatically after 60 days without repository activity.

The job runs at the wrong hour

The preview uses your local time zone, but the scheduler uses its own — often UTC. Convert the intended local time to the scheduler's zone, for example with the Unix Timestamp Converter 's time-zone panel, or set an explicit zone where the platform allows it.

It runs on more days than expected

If both day of month and day of week are restricted, a day matches when either field matches. To run only on Fridays that fall on the 1st–7th, leave one field as * and add the other check in your script.

Uneven gaps with steps

Steps restart at the beginning of each range. */7 in minutes runs at :49 and :56 and then again at :00, only four minutes later; 0 0 */2 * * runs on odd days of the month, so it fires on the 31st and again on the 1st. Cron cannot express "every 48 hours" exactly.

A field is rejected

• Each box holds one field. Pasting a whole expression such as 0 9 * * 1-5 into the Minute box is reported as invalid; use the presets or fill the boxes one by one.
• Shortcuts such as @daily and Quartz-style tokens L, W, # and ? are not accepted. Write the five-field equivalent: @daily is 0 0 * * *.
• In day of week, this tool follows Vixie cron and cronie: both 0 and 7 mean Sunday, so 0-7 is every day and 5-7 is Friday through Sunday. Kubernetes CronJobs accept only 0–6, so use 0 or SUN for Sunday there.
• A step after a single number, such as 20/15 , means “from 20 to the end of the field” (minutes 20, 35 and 50), as in Kubernetes and GitHub Actions. Vixie cron and cronie reject this form in crontab; write 20-59/15 to get the same result everywhere.

• Five fields only. There is no seconds field (used by Quartz and Spring) and no year field (used by Quartz and AWS EventBridge), so expressions for those schedulers need adapting.
• No time-zone selector. Next runs are always shown in your browser's time zone. Around daylight-saving changes, schedulers differ in how they treat a skipped or repeated hour, so be careful with jobs between 01:00 and 03:00 local time, or schedule in UTC.
• Day-field rule. The tool applies the OR rule whenever both day fields are something other than a bare *. Some implementations, such as Vixie cron and cronie, also treat a field that starts with * (for example */2) as unrestricted, so a combination like 0 0 1 * */2 can run on fewer days there than the preview shows.
• It does not run or monitor jobs. The tool only builds and explains expressions; it cannot check your command, environment or whether a job actually ran.

Related: convert run times and epoch values with the Unix Timestamp Converter, and check scheduled-job payloads with the JSON Formatter.