About this tool
This cron expression generator builds standard five-field crontab schedules (minute, hour, day of month, month, day of week) from simple controls, and works in reverse: paste any expression and it is parsed, described in plain English, and expanded into its next ten run times in your local time zone. It accepts the full Vixie cron syntax used by Linux crontab, GitHub Actions, Kubernetes CronJobs, and most schedulers: asterisks, lists, ranges, steps, month and weekday names, 7 as an alias for Sunday, and the @hourly to @yearly shortcuts. It is meant for developers and sysadmins writing crontab entries, CI schedules, or backup jobs who want to see exactly when a schedule will fire before committing it.
How it works
Each field is parsed into the set of values it matches: * means every value, a-b a range, */n or a-b/n every nth value from the start of the range, and comma lists combine any of these. Names (JAN-DEC, SUN-SAT) are mapped to numbers and 7 is folded into 0 for Sunday. To find the next runs the tool walks forward one calendar day at a time (up to five years), keeps days whose month matches and whose day-of-month or day-of-week matches, then emits every matching hour and minute on that day in your local time zone; times that do not exist because of a daylight-saving jump are skipped, as most cron daemons do. Day-of-month and day-of-week are combined with OR when both are restricted, following the crontab(5) rule.
Frequently asked questions
What do the five fields mean?
In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC), and day of week (0-7 or SUN-SAT, where both 0 and 7 mean Sunday). An asterisk matches every value. So 30 2 * * 1 means 02:30 every Monday, and 0 */6 * * * means at minute 0 of every sixth hour: 00:00, 06:00, 12:00, and 18:00.
Why does setting both a day of month and a weekday give more runs than expected?
When both fields are restricted, crontab(5) fires when either one matches, not both. 0 9 1 * MON runs at 09:00 on the first of every month and on every Monday. There is no standard way to express the first Monday of the month in five-field cron; schedule every Monday and have the job itself check the date, or use a scheduler that supports the # extension.
Which time zone are the run times in?
The next-run list uses your browser's local time zone. A cron daemon uses the time zone of the machine or container it runs on, which is often UTC on servers and in CI systems such as GitHub Actions. If your job runs on a UTC server, convert your desired local time to UTC before writing the expression, and remember the offset changes when daylight saving time starts or ends.
What happens to a job scheduled during a daylight-saving change?
When clocks jump forward, a wall-clock time such as 02:30 does not exist that day, and Vixie cron on Linux skips it (some daemons run it once at the new time). When clocks fall back, 01:30 occurs twice and cron runs the job only once. Scheduling critical jobs between 03:00 and 23:59, or running the server in UTC, avoids both problems. This tool skips non-existent local times.