Cron Expression Parser
Convert Cron expressions into human-readable descriptions.
About Cron Expression Parser
A cron expression packs a repeating schedule into a handful of space-separated fields. It is compact and it is unforgiving: a schedule that fires sixty times more often than intended looks almost identical to the one you meant. Type an expression above and it is translated into a sentence as you type, so the mistake surfaces before the job does.
Reading the translation critically
The description is generated from the fields alone, so it reflects your intent rather than your scheduler's behaviour. Two gaps are worth holding in mind. When both the day-of-month and day-of-week fields are restricted, the sentence joins them with "and" while classic cron treats them as an alternative and runs on either. And nothing checks the calendar, so a February the 30th schedule is described as cheerfully as any other.
Field counts differ by platform
Five fields is the Unix crontab standard, and it is what Kubernetes CronJob and GitHub Actions expect. Quartz and Spring add a seconds field at the front, making six. AWS EventBridge also uses six, but its extra field is a year at the end and it requires a question mark in one of the two day fields. Both shapes are handled here, along with the seven-field Quartz form, so 0 0 12 * * ? reads as noon and 0 15 10 ? * 6L 2025 as the last Saturday of each month in 2025.
Shorthand, and what is not accepted
The @hourly, @daily, @weekly, @monthly, @yearly and @reboot macros are understood — the last describes itself as running once at startup, a useful reminder that it is tied to boot rather than to a clock. Jenkins' hashed syntax is not supported: an H asks Jenkins to spread the job across the hour, which is a load-balancing instruction rather than a time, and an expression containing one is simply reported here as Invalid cron expression. The error line is the same for every failure — it names no field and no position — so when it appears, clear fields back to asterisks one at a time to find the one at fault.
Habits that prevent incidents
Avoid the top of the hour for anything heavy — 0 * * * * means every host in the fleet starts at the same instant, and offsetting to 7 * * * * costs nothing. Assume overlapping runs are possible and take a lock, because cron starts the next instance whether or not the previous one has finished. Everything on this page is worked out in the tab with no expression stored or sent anywhere, so it is safe to paste a line straight out of a production crontab while you check it.
Five, Six And Seven Fields
A Quartz expression with a leading seconds field reads correctly, and so does an EventBridge one ending in a year — 0 18 ? * MON-FRI * comes back as "At 06:00 PM, Monday through Friday".
Rejects What It Cannot Read
An unparseable field stops the translation rather than producing a silent guess: the green sentence disappears and a red "Invalid cron expression" line takes its place. Jenkins hashed syntax such as H/15 * * * * is rejected that way.
Fourteen Schedules To Start From
The buttons below the input cover the patterns people actually write — every five minutes, weekday mornings, midnight on the 1st and 15th, Friday evenings — as a starting point to edit.
Frequently Asked Questions
Which field is which?
In the five-field form the order is minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC) and day of week (0-6 or SUN-SAT, with 7 also accepted for Sunday). So 30 8 * * 1 is 08:30 every Monday. The two positions that trip people up are day of month and day of week sitting next to each other, and hour using a 24-hour clock while the description below reads back in 12-hour time.
Why does the description say "and" when both day fields are set?
This is the single most dangerous corner of cron. Enter 0 0 13 * 5 and you are told "on day 13 of the month, and on Friday", but Vixie cron — the implementation behind crontab on Linux and macOS — treats those two fields as an OR whenever both are restricted. The job runs on every 13th and on every Friday, which in a typical year is around sixty runs rather than one or two. If you mean a single day, leave one of the two fields as an asterisk.
What do the special characters do?
An asterisk means every value. A comma builds a list, as in 1,15. A hyphen builds a range, as in MON-FRI. A slash sets a step, so */5 in the minute field fires at 0, 5, 10 and so on, and 0-20/2 restricts the step to part of the range. Quartz adds a question mark for "no specific value" in one of the day fields, L for last, and # for the nth weekday — 0 0 * * MON#2 is the second Monday of each month.
Does it check that the date actually exists?
No. The parser describes the fields it is given without asking whether any calendar date satisfies them. Enter 0 0 30 2 * and you are told "At 12:00 AM, on day 30 of the month, only in February" — a date that never arrives, so the job never fires. February the 29th behaves similarly and only runs in leap years. If a scheduled task has mysteriously never executed, an impossible day-of-month value is worth ruling out first.
Which timezone does the schedule use?
Whichever the runner uses, and this page cannot know that — a cron expression carries no zone of its own. System crontab follows the machine's local time and honours CRON_TZ or TZ at the top of the file. GitHub Actions, AWS EventBridge and most managed schedulers interpret expressions as UTC. Kubernetes CronJob defaults to the kube-controller-manager's zone unless timeZone is set. The practical hazard is daylight saving: on a local-time host, a 02:30 job can be skipped or run twice on changeover days.
Will it tell me the next few run times?
No — this tool translates the expression into English and stops there. Predicting actual fire times means committing to a timezone, a DST policy and one platform's field ordering, and a wrong answer there would be worse than none. For a dry run, most schedulers can list upcoming executions themselves, and croniter or a cron library in your language will do it against a zone you choose.