Developer · Validator
Cron expression parser.
Paste a crontab schedule to check the syntax, read it in plain English and see exactly when it runs next. Runs in your browser; nothing is sent anywhere.
Input
Result
Enter a cron expression and press Parse.
How cron schedules are read
A standard crontab entry has five time fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or jan-dec) and day of week (0-7 or sun-sat, where both 0 and 7 mean Sunday). Each field can be *, a number, a range like 9-17, a list like 1,15, or a step like */15 or 0-30/10.
The day rule that surprises people: when both day-of-month and day-of-week are restricted (neither starts with *), the job runs when either matches, not both. 30 4 1,15 * 5 runs at 04:30 on the 1st and 15th and on every Friday. If only one of the two is restricted, only that one applies.
A step inside a field is evaluated within that field only, so */23 in the hour field means hours 0 and 23 of each day, not every 23 hours.
Not supported: Quartz/Spring-style syntax (?, L, W, #, a seconds or year field), the ~ random-range extension, and @reboot. These are rejected with a message rather than guessed at.
Sources: POSIX crontab (The Open Group Base Specifications, Issue 7) and the crontab(5) manual page for steps, names and nicknames.
Frequently asked questions
What is the difference between this and the cron generator?
The generator assembles an expression from preset fields. This tool goes the other way: you paste any expression, it validates it, explains it and computes the actual upcoming run times.
Which time zone does my server use?
That depends on how cron is configured on the machine, which this page cannot see. Pick UTC or your local time to preview; if your server runs in another zone, compare against that zone's clock.
What happens around daylight saving changes?
Per crontab(5), a wall-clock time that does not exist during the spring change never matches, and a time that occurs twice in the autumn change runs twice. In local mode this page skips non-existent times the same way. UTC has no such changes.
Does it work with AWS, Kubernetes or GitHub Actions cron?
Kubernetes CronJob and GitHub Actions use the standard five-field form, so they parse here. AWS EventBridge uses a six-field format with a year and different rules, which this tool does not accept.
A preview, not your scheduler
Run times are calculated from the standard crontab rules. Your scheduler may differ (time zone, DST handling, vendor extensions), so confirm behaviour against its own documentation before relying on a schedule.