How cron expressions work
A cron expression is a five-field schedule that tells a time-based job runner when to fire. Reading left to right, the fields are minute, hour, day of month, month, and day of week — so 30 8 * * 1-5 means "08:30, Monday through Friday." It's terse, but every scheduler from Unix crontab to Kubernetes speaks it.
Each field accepts four operators: * (every), , (a list), - (a range), and / (a step). The combination is what makes cron expressive — and easy to misread, which is exactly why translating it back to plain English and previewing the next few run times catches mistakes before they ship.
Parsing and the schedule preview run entirely in your browser.
The operators at a glance
Pin a job to exact moments with explicit values and lists.
Repeat on a cadence with the step operator.
Where developers use it
Scheduling backups
Set a nightly database dump and read back the English to be sure it's not firing every minute.
Cleanup jobs
Run a cache or log sweep every few hours and confirm the interval with the next-run preview.
Debugging a missed run
Paste an expression that didn't fire to spot the day-of-month / day-of-week OR trap.
Frequently asked questions
In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, Sunday = 0). A * means "every" value of that field, so * * * * * runs every minute.
* is every value; , lists specific values (1,15,30); - is a range (9-17); and / is a step (*/15 = every 15). They combine — 0-30/10 means 0, 10, 20, 30.
This is the classic gotcha. In most cron implementations, when both the day-of-month and day-of-week fields are restricted (neither is *), the job runs when either matches — an OR, not an AND. If you need "the 1st and only if it's a Monday," cron can't express that directly.
This parser works with the standard 5-field syntax rather than the @daily/@hourly macros. Expand them to their equivalents — @daily is 0 0 * * *, @hourly is 0 * * * *, @weekly is 0 0 * * 0 — and paste those.
It targets the classic 5-field POSIX format. Some schedulers (Quartz, some cron libraries) add a leading seconds field or a trailing year field; drop those extra fields to validate the standard minute-to-weekday portion here.
Traditionally the server's local time, which makes daylight-saving transitions tricky. Many modern schedulers (Kubernetes CronJobs, cloud schedulers) let you set a timezone explicitly or default to UTC — always check which, or a job can fire an hour off twice a year.
No. Parsing and the next-run preview are computed entirely in your browser.