Cron Expression Builder
Build cron schedules with buttons, see the next 10 runs instantly.
100% in your browser. Nothing you type ever leaves this page.
Self-test passed: scheduler verified against 5 reference expressions.
Read the preview, not the expression
Cron syntax is forty years old and optimized for terseness, not for humans. The five fields read minute, hour, day of month, month, day of week, in that order, and the gotchas hide in their interactions. That is why this builder leads with the next-runs list: you check ten concrete timestamps instead of mentally simulating an expression. If the list shows 02:00 UTC when you meant 02:00 Paris time, you just saved yourself a silent 1 a.m. backup.
The mistakes the preview catches
The classic one is * 2 * * * meaning "every minute during the 2 a.m. hour",
sixty runs, when the author wanted 0 2 * * *, one run. Day-of-month plus
day-of-week is the other trap: standard cron ORs them, so "the 13th and also every
Friday" instead of "Friday the 13th". And February quietly skips jobs scheduled on the
29th, 30th or 31st. All three show up instantly in the preview list, which is the point.
Where this syntax works
The 5-field output is the lingua franca: Linux crontab, Kubernetes CronJob, GitHub
Actions schedule, GitLab CI, AWS EventBridge (with a minor dialect change
for day-of-week), Cloudflare Workers triggers. Two ecosystems differ enough to bite:
Quartz (Java) uses 6 or 7 fields with seconds and swaps the day-of-week numbering, and
systemd timers use a different calendar syntax entirely, documented in
systemd.time(7).
When a platform rejects a valid expression, check which dialect it expects first.
Scheduling hygiene that prevents incidents
Avoid the on-the-hour stampede: half the internet schedules at :00, so your API calls hit rate limits exactly then. Pick :07 or :23. Stagger jobs that share a database. And if a job must not overlap with itself, cron will not help you; use flock or a queue, because cron happily starts run two while run one is still going.
Frequently asked questions
Why does my cron job run at the wrong hour?
Almost always a timezone story. Cron evaluates the schedule in the timezone of the machine (or container) running it, which is often UTC on servers while you think in local time. This tool shows the next runs in both your local time and UTC so the offset stares back at you before you deploy.
What does */5 actually mean?
Every value divisible by the step, starting from the field minimum. In the minute field, */5 fires at :00, :05, :10 and so on. Note that */5 in the hour field means 0:xx, 5:xx, 10:xx, 15:xx, 20:xx, which is rarely what people want for "every 5 hours from now": cron has no notion of "from now".
What happens when both day-of-month and day-of-week are set?
Standard (Vixie) cron treats them as OR, not AND: "0 0 13 * 5" fires on the 13th of every month AND on every Friday, which surprises nearly everyone. This builder follows the standard and the preview shows the real result, so the surprise happens here instead of in production.
Does this support seconds or the @daily shortcuts?
The builder produces standard 5-field expressions, the format crontab, Kubernetes CronJobs and most CI systems accept. Quartz-style 6 or 7 field expressions with seconds are a different dialect. The @daily, @hourly and @reboot shortcuts are crontab-only sugar; we output their explicit equivalents so they work everywhere.
Why did my job not run while the server was off?
Plain cron has no catch-up: a missed time is gone. If the machine sleeps or reboots through the scheduled minute, nothing fires afterward. For laptops and intermittent machines, use anacron or a systemd timer with Persistent=true, which run the job once the machine is back.