Cron Expression Generator
Build, validate, and explain cron expressions visually.
Disclaimer: The results provided by this tool are estimates for informational purposes only. Actual values may vary. Please verify important calculations independently.
How cron parses a schedule
A cron expression is evaluated field by field from left to right: minute, hour, day of month, month, and day of week. The scheduler wakes up once per minute and asks a simple question for each active job — does the current wall-clock minute satisfy every field? If all five fields match, the command runs. That is why the order matters so much: swapping the hour and day-of-month positions changes a daily 9 AM job into something that only fires on the 9th of each month. The expression '30 14 * * *' means the 30th minute of the 14th hour on any day, any month, any weekday — in other words, 2:30 PM daily.
The fifth field, day of week, interacts with the third field, day of month, using OR logic rather than AND. An expression like '0 0 1 * 1' fires at midnight on the 1st of the month OR any Monday, not only Mondays that happen to fall on the 1st. This surprises newcomers regularly. Most cron implementations also support step values with the slash character, ranges with hyphens, and comma-separated lists, which let you compose expressions like '*/5 9-17 * * 1-5' to mean every five minutes during business hours on weekdays without writing out each value.
Common pitfalls when scheduling jobs
The two questions that trip people up most often are time zone and overlap. Traditional Unix cron runs in the local time zone of the machine, which means a server migration or daylight saving transition can silently shift when your job fires. During the spring-forward hour, a 2:30 AM job may be skipped entirely; during the fall-back hour, it may run twice. Many modern schedulers — Kubernetes CronJobs, AWS EventBridge, GitHub Actions — default to UTC for exactly this reason, so verify which clock your cron expression will be evaluated against before you debug a missing run.
Overlap happens when a previous invocation has not finished before the next one is due. Cron will happily launch a fresh process every minute even if nine earlier copies are still grinding through the last batch. For long-running jobs, wrap the command in a lockfile tool like flock, or use a scheduler that offers concurrency controls natively. Also remember that cron does not retry on failure: if the machine was asleep or the job exited non-zero, the slot is simply missed. Pair any important cron expression with external monitoring that alerts you when an expected run does not produce its usual output.