Cron Generator — build and preview cron schedules
Pick a preset or fill in the five fields manually. The tool shows the cron expression, a plain-English description, and the next five times the schedule will fire (UTC).
Pick a preset or fill in the five fields manually. The tool shows the cron expression, a plain-English description, and the next five times the schedule will fire (UTC).
0 9 * * 1-5At 09:00, on weekday 1-5 (0=Sun)
A cron expression is a five-field schedule string (minute, hour, day-of-month, month, day-of-week) used by Unix's cron daemon since the 1970s and inherited by every modern scheduler — systemd timers, Kubernetes CronJobs, GitHub Actions schedules, AWS EventBridge, BullMQ, and most CI/CD systems all read it.
Each field accepts a number, a wildcard (*), a range (1-5), a list (1,3,5), or a step (*/15). The expression '0 9 * * 1-5' means 'at 09:00 on every Monday through Friday'. This generator helps you compose the expression by typing each field with hints, then validates by computing the next firing times in your timezone.
Minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-6, where 0 = Sunday). Some systems extend the format with a seconds field at the start (Quartz, Spring); this tool produces the standard 5-field POSIX form.
Yes. '0,30 9-17 * * 1-5' means at minute 0 and 30 of hours 9 through 17 on weekdays. You can also combine a step: '*/15 8-20 * * *' fires every 15 minutes between 08:00 and 20:00.
Fires every minute. Useful as a sanity-check schedule when developing, but rarely what you want in production — most jobs become 'thundering herd' if they run that often.
UTC. Display in UTC keeps the schedule unambiguous when comparing with server logs or other systems. To check what the cron means in your local time, mentally add or subtract your offset from the UTC time shown.
Cron schedules a job at the start of the matching minute. The actual run starts a few seconds after, depending on system load and other queued jobs. If you need sub-minute precision, cron is the wrong tool — use a job runner with sub-second resolution.
Where dialing in a cron expression saves real frustration.
'0 3 * * *' runs at 03:00 every night, when load is lowest. Combine with a retention policy and you have a low-cost backup pipeline that nobody has to think about.
'0 9 * * 1' fires every Monday at 09:00 — perfect for a weekly summary email landing in your team's inbox at the start of the work week.
'*/5 * * * *' every five minutes is the sweet spot for cache refreshes that need to be fresh but not so frequent they're hammering the source.
'0 4 * * 0' once a week (Sunday 04:00) is enough for log rotation, expired session purges, or temp file cleanup that doesn't need to happen daily.
Habits that make cron expressions less error-prone.
If you have multiple cron jobs and they all start at minute 0, your server gets a load spike every hour. Start them at different minutes (0, 7, 13, 19…) to spread the work and avoid contention.
When both DOM and DOW are set, classic cron fires when EITHER matches (an OR), not both. Most modern schedulers (Quartz, Kubernetes) honour both as AND. Test on your specific platform if you set both.
Cron expressions are write-once read-many. Add a # comment line above each entry explaining what the job does — your future self in three months will thank you.
Cron daemons honor the system timezone, which can flip between standard and daylight saving. For schedules that must run at the same wall-clock hour year-round, pick a fixed-offset timezone (UTC) and convert in your job code if needed.