Cron Expression Parser & Builder
Read Unix, Spring, Quartz and AWS cron expressions, see the next run times in any time zone, or build an expression field by field.
Schedule
Field breakdown
| Field | Expression | Values |
|---|
Next run times
Visual builder
Choose how each field repeats. “Specific values” takes a list such as 1,15 or MON,WED; “Range” takes from-to such as 9-17; “Every N” takes the step.
Special characters
| * | Every value of the field. |
| , | List of values, e.g. 1,15,30. |
| - | Range, e.g. 9-17 or MON-FRI. |
| / | Step, e.g. */15 = every 15; 5/15 = from 5 every 15 (not in Unix cron). |
| ? | No specific value. Quartz and AWS require it in either day-of-month or day-of-week. |
| L | Last: L in day-of-month = last day; L-3 = three days before it; 5L in day-of-week = last Thursday (Quartz numbering). |
| W | Nearest weekday: 15W = the weekday closest to the 15th; LW = last weekday of the month. |
| # | Nth weekday of the month: 6#3 = third Friday in Quartz/AWS (1 = Sunday); 5#3 in Spring (0 = Sunday). |
| @daily … | Macros: @yearly, @monthly, @weekly, @daily, @hourly; @reboot runs once at startup. |
How to use
- Type or paste a schedule into "Cron expression", or click one of the presets, which also sets "Format" to "Auto detect". The summary and the run times update as you type.
- Leave "Format" on "Auto detect" or select the system the expression is written for. Auto detect reads 5 fields as Unix and 7 as Quartz. For 6 fields it picks AWS or Quartz from the position of "?", picks AWS when the last field contains a year from 1970 to 2199, and otherwise assumes Spring. Macros such as @weekly are read as Unix. When the expression is valid, the status line names the format that was used.
- Read "Schedule" and "Field breakdown" to see what each field matches, then check the dates under "Next run times". "Time zone" starts with your browser's zone; select another one if needed and choose 5, 10 or 20 under "Next runs to show". For zones other than UTC, each run also shows the UTC time.
- To build an expression instead, open "Visual builder", select a format and choose how each field repeats, entering a value where the field asks for one. "Use this expression" copies the "Generated expression" into "Cron expression", sets "Format" to the builder's format and parses it, so you can check the run times.
Frequently asked questions
Is the expression I enter sent anywhere?
No. The expression is parsed and the run times are calculated in your browser with JavaScript; it is not uploaded to LeedyBox.
Why does 0 0 13 * 5 run on every Friday and not only on Friday the 13th?
In Unix cron, when both day of month and day of week are restricted (neither starts with *), a day matches if either field matches, so this runs on the 13th of each month and on every Friday. The tool applies this rule to Unix expressions, and "Schedule" then says "either one is enough". For Spring expressions it requires both fields to match, and Quartz and AWS avoid the question by requiring "?" in one of the two fields. In Unix cron, a common workaround is to schedule every Friday and check the date inside the job.
Is Sunday 0, 1 or 7?
It depends on the format. In Unix and Spring expressions, 0 and 7 both mean Sunday and 1 is Monday; in Quartz and AWS, 1 is Sunday and 7 is Saturday, so 1-5 means Sunday to Thursday there. Day names such as MON-FRI avoid this difference in Spring, Quartz and AWS.
Why is my crontab line or AWS cron( ) expression rejected?
Enter only the schedule fields. The command at the end of a crontab line, and the user name in /etc/crontab, are counted as extra fields, so the tool reports an invalid field or the wrong number of fields. For AWS, paste the six fields from inside cron( ) without the wrapper.
How do I rewrite a Unix expression for Spring, Quartz or AWS?
Spring adds a seconds field at the start, so 0 9 * * 1-5 becomes 0 0 9 * * 1-5. Quartz also needs "?" in one of the day fields and numbers Sunday as 1, so the same schedule is 0 0 9 ? * MON-FRI. AWS has no seconds field, needs "?" in one of the day fields like Quartz, and adds a year at the end: 0 9 ? * MON-FRI *. If the Unix expression restricts both day fields, it relies on the either-or rule described above, which these formats do not use, so you usually need two schedules. Check the result with the target format selected and compare the next run times.
Why does the tool say that no run time was found?
The expression is valid, but no matching time was found in the roughly 8 years ahead that the tool searches. Typical causes are dates that do not exist, such as 0 0 30 2 * (February 30) or day 31 combined only with months that have 30 days, and a year field that lies in the past. A year more than 8 years ahead gives the same message, although that schedule can still run later. Some schedulers, including classic Unix cron, accept a date that does not exist without a warning, and the job does not run.
Which time zone is used, and what about daylight saving time?
Run times are calculated for the zone selected under "Time zone". Choose the one your scheduler uses: crontab usually follows the server's time zone, scheduled rules in AWS EventBridge use UTC, and EventBridge Scheduler lets you set a time zone. The menu offers your browser's zone, UTC and a selection of common zones; if your scheduler's zone is not there, pick one with the same UTC offset and daylight saving dates. A run at a time skipped when the clocks go forward is left out of the list, and a time that occurs twice when they go back is listed once. Cron daemons handle these hours in different ways; cronie, for example, can run a job from a skipped hour right after the change. Check your scheduler's behavior, or use UTC, which has no daylight saving time.