Cron Expression Parser

Enter input above to see the result.

Decoding an existing crontab

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.

Validation, translation, and schedule debugging

• 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.

Reading fire times from an expression

• 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 ranges and allowed syntax

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

OR logic, step resets, and timezone drift

• 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.

Spotting the */15 trap in a live schedule

Enter 0 9 * * 1-5. The tool reads it as "at 09:00, Monday through Friday" and lists the next 10 fire times in your local zone so you can eyeball them. Change it to */15 9-17 * * * and it becomes "every 15 minutes, between 09:00 and 17:59, every day" — a fast way to catch the classic mistake of thinking */15 means "15 past the hour" when it actually fires at :00, :15, :30 and :45.

Field counts, step phases, and day-field surprises

Five fields or six? This parses standard 5-field crontab (minute, hour, day-of-month, month, day-of-week). The 6-field variant with a leading seconds column is a Quartz/Kubernetes extension — drop the seconds field before pasting here.

Does */N mean "every N"? Not exactly — it means "every N starting from the field's minimum." */20 in minutes fires at :00, :20, :40, then :00 again, so the gap from :40 back to :00 is 20 minutes but the pattern resets each hour rather than running a true rolling interval.

What happens if I set both day-of-month and day-of-week? Most cron implementations OR them — 0 0 15 * 1 runs on the 15th or any Monday, not only Mondays that fall on the 15th. This tool follows that convention; it trips up almost everyone.

Which timezone are the fire times in? Your browser's local zone. The cron daemon on a server uses that machine's timezone (often UTC), so verify the server's TZ before trusting a schedule copied from here.

DST transitions and month-boundary gotchas

• Daylight saving time shifts fire times. A job scheduled at 0 2 * * * will skip the 2 AM run on the spring-forward night (that hour doesn't exist) and may run twice on the fall-back night. If your job is time-sensitive, schedule it outside the 1–3 AM window or run the daemon in UTC.
• Day 31 doesn't exist in every month. 0 0 31 * * fires only in months with 31 days — it silently skips February, April, June, September, and November. Use 0 0 28-31 * * with application-level dedup if you want "last day of month" behaviour.