Sanity-checking a cron line in crontab -e before saving — catch mistakes locally instead of discovering them when the job fails to run. Translating a Kubernetes CronJob schedule string into "what time will this actually run?" — convert the expression to a human-readable schedule and preview times. Designing a new schedule from scratch — start with English ("every weekday morning at 9 AM") and iterate the expression until the preview matches your intent. Debugging a job that "didn't run when I expected" — paste the existing schedule, examine the next 10 fire times, and identify whether reality or the expression was the surprise. Learning cron syntax — use the plain-English translation and preview output as feedback while experimenting with field values and wildcards. Comparing schedule across different systems — confirm that a cron expression means the same thing in standard 5-field crontab, systemd timers, or CI/CD platforms.

Enter a standard 5-field crontab expression (minute, hour, day of month, month, day of week). The parser validates the syntax and generates a plain-English description of when the job runs. The tool then calculates and displays the next 10 fire times, using your browser's local timezone. If there are syntax errors, you'll see a clear message identifying the invalid field.

Field Range Wildcards Minute 0-59 * · */5 · 0,30 · 0-29 Hour 0-23 same Day of month 1-31 same Month 1-12 same Day of week 0-6 (0 = Sunday, 7 also = Sunday) same

Day-of-month and day-of-week interact. If both fields are restricted (e.g. 15 * * * 1 meaning "the 15th OR a Monday"), most cron implementations OR them together. This tool follows that convention. */N isn't quite "every N". It means "every N starting from the field's lower bound", so */15 in the minute field gives 0, 15, 30, 45 (not 12, 27, 42, 57). To start at a different offset, use an explicit list: 5,20,35,50 . Step syntax inside ranges. 0-30/5 expands to 0, 5, 10, 15, 20, 25, 30. The step applies only within the specified range. Timezone is browser-local. This tool displays fire times in your local timezone, but real cron daemons run in server time (often UTC). A schedule that looks correct in your browser may fire at a different wall-clock time on the server. Always confirm the server's timezone before deploying. Cron flavours vary. Quartz adds seconds and year fields (6 or 7 fields total). systemd timers use an entirely different format. This tool parses only standard 5-field POSIX crontab syntax.

Cron Expression Parser

Parse cron expressions and see the next 10 fire times. Standard 5-field crontab.

Cron expression (5 fields: minute hour day-of-month month day-of-week)

Next 10 fire times (local timezone)

Enter input above to see the result.

What is this for?

Cron expressions are powerful and easy to mis-write. A single typo or misremembered syntax rule can cause a job to run at the wrong time, not at all, or far more often than intended. This tool validates 5-field crontab syntax, translates the expression into plain English, and previews the next 10 scheduled fire times so you can confirm the schedule before deploying to production.

When to use it

Sanity-checking a cron line in crontab -e before saving — catch mistakes locally instead of discovering them when the job fails to run.
Translating a Kubernetes CronJob schedule string into "what time will this actually run?" — convert the expression to a human-readable schedule and preview times.
Designing a new schedule from scratch — start with English ("every weekday morning at 9 AM") and iterate the expression until the preview matches your intent.
Debugging a job that "didn't run when I expected" — paste the existing schedule, examine the next 10 fire times, and identify whether reality or the expression was the surprise.
Learning cron syntax — use the plain-English translation and preview output as feedback while experimenting with field values and wildcards.
Comparing schedule across different systems — confirm that a cron expression means the same thing in standard 5-field crontab, systemd timers, or CI/CD platforms.

How it works

Enter a standard 5-field crontab expression (minute, hour, day of month, month, day of week).
The parser validates the syntax and generates a plain-English description of when the job runs.
The tool then calculates and displays the next 10 fire times, using your browser's local timezone.
If there are syntax errors, you'll see a clear message identifying the invalid field.

Cron field reference

Field	Range	Wildcards
Minute	0-59	`` · `/5` · `0,30` · `0-29`
Hour	0-23	same
Day of month	1-31	same
Month	1-12	same
Day of week	0-6 (0 = Sunday, 7 also = Sunday)	same

Common gotchas

Day-of-month and day-of-week interact. If both fields are restricted (e.g. 15 * * * 1 meaning "the 15th OR a Monday"), most cron implementations OR them together. This tool follows that convention.
*/N isn't quite "every N". It means "every N starting from the field's lower bound", so */15 in the minute field gives 0, 15, 30, 45 (not 12, 27, 42, 57). To start at a different offset, use an explicit list: 5,20,35,50.
Step syntax inside ranges. 0-30/5 expands to 0, 5, 10, 15, 20, 25, 30. The step applies only within the specified range.
Timezone is browser-local. This tool displays fire times in your local timezone, but real cron daemons run in server time (often UTC). A schedule that looks correct in your browser may fire at a different wall-clock time on the server. Always confirm the server's timezone before deploying.
Cron flavours vary. Quartz adds seconds and year fields (6 or 7 fields total). systemd timers use an entirely different format. This tool parses only standard 5-field POSIX crontab syntax.