Cron Parser
Parse a Cron expression, compute the next 5 run times and explain it in words
Common presets
Field breakdown
Minute
0
Values
0
Hour
9
Values
9
Day
*
Values
Unrestricted
Month
*
Values
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Weekday
1-5
Values
1, 2, 3, 4, 5
Meaning
- 09:00
- Monday, Tuesday, Wednesday, Thursday, Friday
Next 5 run times
- #12026-10-12 (Mon) 09:00
- #22026-10-13 (Tue) 09:00
- #32026-10-14 (Wed) 09:00
- #42026-10-15 (Thu) 09:00
- #52026-10-16 (Fri) 09:00
Last updated: 2026-10-10
About this tool
The hard part of Cron is never the syntax - it is a handful of counter-intuitive rules, above all that when both day-of-month and day-of-week are set the relationship is OR rather than AND, and that Sunday can be either 0 or 7. This tool expands every field value individually and computes the next five run times, so the consequences of those rules are visible straight away instead of only surfacing when a production job runs at the wrong time.
Features
Two field formats
Automatically detects the 5-field form (minute hour day month weekday) and the 6-field form (second minute hour day month weekday) without you having to pick a mode.
Field value expansion
Lists the actual values of every field in full. Seeing which minutes `*/15` really hits is far more reliable than reasoning it out in your head.
Next run times
Computes the next five exact run times with a switchable time zone. Boundaries such as month rollovers, year rollovers and 29 February in a leap year are all handled correctly.
OR-semantics warning
When both day-of-month and day-of-week are set to something other than *, the standard specifies OR rather than AND. That counter-intuitive rule can send a schedule badly wrong, so the tool warns about it.
Common presets
Built-in presets for every minute, hourly, daily at midnight, weekdays at 9am, monthly on the 1st and more - apply one with a click and fine-tune from there.
Aliases and month abbreviations
Aliases such as @daily and @hourly are expanded before parsing; month names accept three-letter abbreviations like jan, feb, and weekdays accept 0-7 (both 0 and 7 are Sunday).
How to use
- 1
Enter the expression
Type it in or pick a preset. A wrong field count is reported clearly, stating whether 5 or 6 fields are expected.
- 2
Check the field expansion
Compare each field’s expanded values against what you intended, especially where steps or ranges are involved.
- 3
Verify the run times
Look at the next five run times - the most intuitive check there is. Boundary cases across months and years show up here.
- 4
Confirm the time zone
Servers usually run on UTC while you may be thinking in Beijing time. Re-checking after switching time zones prevents the classic “eight hours out” incident.
Options
- Field order
- The standard form is five fields: minute hour day month weekday. The with-seconds form is six: second minute hour day month weekday. This tool detects which by the field count.
- Asterisk *
- Means the field is unrestricted and takes every possible value. In the minute field, every minute.
- Range a-b
- An inclusive range from a to b. Writing 9-18 in the hour field means every hour from 9 through 18.
- Step /n
- Used with * or a range to mean every n units. Writing */15 in the minute field means minutes 0, 15, 30 and 45.
- List a,b,c
- Lists several values separated by commas, and can be mixed with ranges - 0,10-12 means minutes 0, 10, 11 and 12.
- Day-of-month vs day-of-week OR semantics
- When neither field is *, satisfying either one is enough to trigger. So “0 0 13 * 5” means the 13th of the month **or** every Friday, not both. This is the behaviour the Cron specification defines.
- Sunday
- Both 0 and 7 mean Sunday and are equivalent. This tool normalises 7 to 0, so both spellings produce identical results.
- Month and weekday abbreviations
- Months accept three-letter abbreviations such as jan and feb (case-insensitive); standard Cron also allows sun and mon for weekdays, but implementations vary widely in support, so plain numbers are safer.
Common use cases
- Verifying an expression before configuring a scheduled job
- Investigating why a job did not run when expected
- Confirming exactly which moments an expression with steps will hit
- Checking the time-zone difference between a UTC server and local time
- Translating an expression copied from someone else’s code into plain words
- Checking that boundary dates such as month-ends and year-ends trigger correctly
- Understanding what actually happens when both day and weekday are set
FAQ
Questions you may have about this tool
Why is my job running far more often than expected?
You have almost certainly hit the day-or-weekday semantics trap. When both the day-of-month and day-of-week fields are set, Cron specifies OR rather than AND - `0 0 13 * 5` means the 13th of the month **or** every Friday, not “the 13th when it is a Friday”. To have day and weekday both apply you need another mechanism or a more explicit expression.
What is the difference between * and ?
In standard Cron both mean “unrestricted” and this tool treats them the same. The difference is that some implementations (Quartz, for instance) require one of the day-of-month or day-of-week fields to be ? to say explicitly that the field is unset, sidestepping the ambiguity of the OR semantics. Standard Cron simply uses *.
Do both 0 and 7 mean Sunday?
Yes, they are equivalent. It is a historical legacy: early implementations used 0 for Sunday, and 7 was introduced later to support 1-7 numbering. This tool normalises 7 to 0, so both spellings give identical results.
How do I write an expression with seconds?
Add a “second” field in front of the standard five, making six. For example `30 0 9 * * *` runs daily at 09:00:30. Note that not every scheduler supports second precision - standard cron’s smallest unit is a minute, and only frameworks such as Quartz and Spring support the 6-field form.
How do I express “the last day of the month”?
Standard Cron has no direct “month end” syntax, and writing 31 makes it skip February, April and other months without a 31st. The usual workarounds are writing `28-31` and re-checking inside the script, or using an implementation that supports L syntax (Quartz uses `L` for the last day of the month). This tool does not support L and reports a clear error if it sees one.
Why does a job set for 29 February run so rarely?
Because 29 February exists only in leap years, roughly once every four years. This tool’s calculation correctly skips non-leap years - you can use it to confirm that the next trigger really is a leap year rather than a misconfiguration.
Does the time zone affect when a job runs?
It does, and significantly. Servers usually run on UTC while you may be thinking in Beijing time, eight hours apart. If you want a job at 09:00 Beijing time, on a UTC host you should write `0 1 * * *`, not `0 9 * * *`. This tool lets you switch the time zone to check.
Are my expressions uploaded?
No. Parsing and time calculation happen entirely in your browser with no network requests. Expressions can carry business information - that a reconciliation job runs at 3am, say - and this tool never touches that content.