Cron Next Run Calculator
Paste a cron expression to see its meaning and next 10 run times in your timezone.
Cron Expression
Common Presets
Description
Next 10 Runs
Times shown in your local timezone:
Paste a cron expression to see its meaning and next 10 run times in your timezone.
Times shown in your local timezone:
Paste any standard cron expression and instantly see what it means in plain language plus the next ten times it will fire, all in your own timezone. It is the fastest way to verify a schedule before deploying it to crontab, GitHub Actions, or a CI pipeline. Everything runs in your browser, so schedules from private infrastructure are never sent anywhere.
Type a five-field expression into the input box and press Calculate or Enter. The Description card renders a plain-language summary, and the Next Runs list shows ten absolute timestamps, each with a relative countdown such as “in 3 hour(s)”. A timezone name above the list tells you which clock the times refer to. Seven presets cover the most common schedules — every minute, every five minutes, hourly, daily at 09:00, weekdays at 09:00, every Monday, and the first of the month — and clicking one recalculates immediately. Use the copy button to grab all ten formatted times as text for a ticket or runbook.
A cron expression is five space-separated fields read left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–7, where both 0 and 7 mean Sunday). Each field accepts a single value (30), a wildcard (*), a list (1,15), a range (1-5), or a step (*/10). Fields are separated by any whitespace, so extra spaces are tolerated, but the count must be exactly five.
The tool combines two well-tested libraries: one produces the human-readable description, and a full cron engine computes the actual fire times. That second part matters, because the description can look right while the times reveal an off-by-one in a range or a field in the wrong position.
Assume it is Friday, 11 September 2026, mid-afternoon, and the browser is on local time.
0 9 * * 1-5 — “At 09:00 AM, Monday through Friday”. The next runs are Monday 14, Tuesday 15, Wednesday 16, Thursday 17, and Friday 18 September, all at 09:00. Saturday and Sunday are absent, confirming the weekday range.
*/15 * * * * — “Every 15 minutes”. The list steps 15 minutes at a time from the next quarter hour.
0 0 1 * 1 — this is the OR case. It fires at midnight on Monday 14 September, again on Monday 21 and Monday 28, then next on Thursday 1 October, because the first of the month falls on a Thursday. Seeing the 1st appear out of the Monday sequence is the clearest way to understand the OR behavior.
30 6 1,15 * * — “At 06:30 AM, on day 1 and 15 of the month”. Use this pattern for semi-monthly payroll or billing jobs.
| Field | Position | Allowed values | Useful patterns |
|---|---|---|---|
| Minute | 1 | 0–59 | */5, 0,30, 15-45 |
| Hour | 2 | 0–23 | */6, 9, 9-17 |
| Day of month | 3 | 1–31 | 1, 1,15, */2 |
| Month | 4 | 1–12 | 1, 1-6, */3 |
| Day of week | 5 | 0–7 (Sun = 0 or 7) | 1-5, 1,3,5, 0 |
A step can be combined with a range, so 10-50/10 in the minute field matches 10, 20, 30, 40, and 50. Lists and ranges can be mixed, as in 0 8,12,18 * * 1-5. Comma-, hyphen-, and slash-based syntax is the whole language; anything beyond that, such as the L, W, or # tokens from Quartz, is not supported here and should be rewritten or tested in the scheduler that understands it.
This is the single most surprising rule in cron, and it is where most schedule bugs originate. When one of the two day fields is a wildcard, the other one controls the schedule normally: 0 0 * * 1 runs every Monday. But when both are restricted, standard cron treats them with OR, so 0 0 1 * 1 means “the 1st, or any Monday” rather than “the 1st only if it is a Monday”.
There is no standard syntax to force AND inside the expression itself. The usual workarounds are to schedule the job daily and exit early unless the date matches both conditions, or to use two separate scheduled jobs that delegate to the same command. Checking the calculated list is the fastest way to see whether your expression is actually OR-ing.
1 is Monday, not Sunday, and 0 and 7 both mean Sunday.30 9 is 09:30; 9 30 is invalid because hour 30 is out of range.All times are calculated and displayed in your browser's local timezone, detected automatically and shown by name above the results. The cron engine interprets the fields against that same local clock. If a server runs jobs in UTC, its actual fire times will differ from what you see unless your browser is also set to UTC.
This calculator accepts exactly five fields: minute, hour, day of month, month, and day of week. Quartz and Spring add a leading seconds field and some schedulers append a year, so expressions copied from those systems have one or two extra columns. Remove the seconds (and any year) field before calculating.
The step syntax */5 means every fifth value across the field's full range, so in the minute field it matches 0, 5, 10, 15, and so on up to 55. The same syntax works in any field: */6 in the hour field fires at 0, 6, 12, and 18.
When both the day-of-month and day-of-week fields are restricted, standard cron combines them with OR, not AND. That expression runs at midnight on the first of the month and on every Monday. To require both conditions, you need an application-level check inside the job.
Yes, because the calculation uses the browser's local timezone at the moment you press Calculate. Move the machine to another zone or change the OS clock and the listed moments shift accordingly, even though the expression is unchanged. Refresh the page to pick up a new timezone.
The fifth field is the day of week, numbered 0 or 7 for Sunday through 6 for Saturday. The range 1-5 selects Monday through Friday, so weekend days are excluded. The plain-language description confirms this as Monday through Friday.
Reviewed by the HandyTools Hub team · Last updated