// the lab · cron explainer
Paste a cron expression and read it in plain English. See the next run times in any time zone, catch the classic gotchas, and copy it as a crontab line, a systemd timer or a Kubernetes CronJob.
$ fields 5 or 6 (with seconds)
$ output english · next runs · systemd · k8s
$ upload --to-server never
// how it works
01
Type or paste a cron expression, a macro such as @daily, or a whole crontab line. Each field is labelled so you can see which number is which.
02
Get a plain-English sentence, a field-by-field breakdown and the next 5 to 50 run times in your server’s time zone, with UTC alongside.
03
Copy a commented crontab line, a systemd OnCalendar timer or a Kubernetes CronJob schedule, or share a link to the exact expression.
// cheat sheet
Five fields, four symbols, a few macros. That covers almost every schedule you will ever write.
| symbol | meaning | example | runs |
|---|---|---|---|
* | every value | * * * * * | every minute |
, | list | 0 8,20 * * * | 8:00 and 20:00 |
- | range | 0 9 * * 1-5 | 9:00, Monday to Friday |
/ | step | */10 * * * * | every 10 minutes |
| names | months and weekdays | 0 12 * JAN,JUL MON | noon on Mondays in January and July |
@daily | macro | @daily | same as 0 0 * * * |
@reboot | macro | @reboot | once at startup |
Field order: minute (0-59) · hour (0-23) · day of month (1-31) · month (1-12) · day of week (0-7, 0 and 7 are Sunday).
// faq
Run every 5 minutes: at minute 0, 5, 10 and so on, every hour of every day. The */5 in the minute field means “every value from 0 to 59 in steps of 5”.
When you restrict both the day of month and the day of week (for example 0 0 13 * 5), classic cron runs the job when EITHER matches, so it runs on every Friday and on every 13th. The explainer warns you about this. To require both, check the date inside the script.
The time zone of the server or container running the cron daemon, which is often UTC on cloud servers. Kubernetes CronJobs use the controller’s zone unless you set spec.timeZone. Pick the matching zone in the explainer to see real run times.
Linux crontab uses 5 fields, starting with minutes. Spring, Quartz and some cloud schedulers add a seconds field at the front, making 6. The explainer reads 6-field expressions with seconds first and warns that classic crontab will not accept them.
Times that do not exist (the skipped hour in spring) are shifted forward, and repeated times in autumn run once. Exact behaviour differs between cron implementations, so avoid scheduling critical jobs between 1 AM and 3 AM in zones with daylight saving, or run the server in UTC.
Copy the systemd block the tool generates into a .timer file, pair it with a .service file that runs your command, then enable it with systemctl enable –now name.timer. Persistent=true makes missed runs happen after a reboot.
No. Those are Quartz-only extensions (last day, nearest weekday, nth weekday) that Linux cron does not understand. The explainer tells you when an expression uses them.
// more from the lab
Built by roosho, a jack of all IT trades. Runs in your browser. No account, no upload.
