Cron Generator

A cron expression describes a recurring schedule in five fields: minute, hour, day of month, month, day of week. Each field is either a specific value, a range, a list, a step, or * meaning “every”. The job runs whenever the current time matches every field at once.

So 0 9 * * 1-5 reads as: minute 0, hour 9, any day of the month, any month, Monday to Friday — nine o'clock on weekdays.

This tool generates and validates standard five-field Unix cron, the syntax used by crontab, cronie, Vixie cron and most Linux distributions. Being explicit matters, because the dialects differ:

• Not supported: a leading seconds field. Six fields means Quartz or Spring, and crontab will reject it. The validator says so specifically rather than reporting a generic error.
• Not supported: Quartz extensions such as L (last), W (nearest weekday) and # (nth weekday).
• Supported: *, ranges (1-5), lists (1,15,30), steps (*/15, 0-30/5), and the three-letter month and day names.
• Supported: the @daily, @hourly, @weekly, @monthly and @yearly shortcuts.

Sunday is both 0 and 7. Most implementations accept either, so 0-6 and 1-7 both cover a full week — but from different starting days.

Day of month and day of week are OR-ed, not AND-ed. This is the genuinely surprising one. If both fields are set to something other than *, the job runs when either matches. So 0 0 13 * 5 runs on every 13th and on every Friday — not only on Friday the 13th. To require both, you must check the day inside the job itself.

1. Edit any builder field, or type an expression directly — the two stay in sync.
2. Read the plain-English description to confirm it says what you meant.
3. Check the next five run times, which is the fastest way to catch a mistake.
4. Switch between local time and UTC — servers almost always run cron in UTC.

• Scheduling a nightly backup, a cache warm or a cleanup job.
• Configuring a Kubernetes CronJob or a CI schedule.
• Working out what an inherited expression in an old crontab actually does.
• Checking whether a schedule will fire when you think it will, across a daylight-saving change.

• Predicted run times assume the schedule runs in the selected time zone. A server running in UTC will fire at different local times than the local preview suggests.
• Daylight-saving transitions are genuinely ambiguous for cron. A job scheduled at 02:30 may be skipped or run twice on the changeover day, depending on the implementation.
• The preview assumes the job runs exactly on schedule. Real cron daemons can be late under load, and a missed window is usually not made up.
• Non-standard implementations may accept syntax this validator rejects, and vice versa. When in doubt, test against the system that will actually run it.