Why do I need to enter a "from" date?

Next-run times depend on a starting point. Requiring an explicit date keeps the result reproducible — the same expression and date always produce the same five run times, unlike a tool anchored to "right now."

What time zone are the run times shown in?

UTC, always — the same time zone standard cron uses on most servers and the one GitHub Actions and most CI schedulers run in. Convert manually if your scheduler runs in local time.

Does this support 6-field cron with seconds?

Yes — a 6-field expression is read as second, minute, hour, day of month, month, day of week (for example `30 0 9 * * *` is 09:00:30 every day). Note that crontab and GitHub Actions only accept the 5-field form, so drop the seconds field before using the expression there.

What happens with an invalid expression?

The exact parser error is shown — for example, too few fields or a value out of range for its field — instead of a silent failure.

Cron Expression Explainer

Paste a cron expression to get a plain-English description and the next 5 run times, computed from a date you choose. Runs entirely in your browser.

Loading tool…

Worked examples

Every 15 minutes
The everyday case: a short-interval schedule, read out in plain English plus the exact next five run times computed from a given starting point.
Weekdays at 9 AM UTC
A weekday-only business-hours schedule, showing how the next-run calculation correctly skips the weekend between Friday and Monday.
An expression with too few fields
A pasted non-cron string is a common mistake — the parser's exact error is surfaced instead of a blank or misleading result.

What this tool does

This tool takes a cron expression and translates it into a plain-English description, then computes the next five times it would fire, starting from a date you specify. Both the explanation and the run times are computed from the expression itself — there's no guessing or approximation involved.

When you need it

Understanding a cron line you inherited in someone else's crontab, deployment script or CI configuration, without mentally parsing five space-separated fields.
Confirming that a schedule you're about to deploy actually fires when you think it does, before it runs unattended for the first time.
Debugging why a scheduled job ran at an unexpected time, by checking exactly when the next several runs are calculated to occur.
Reviewing someone else's pull request that adds or changes a scheduled job, to sanity-check the schedule without running it yourself.

Why you have to provide a starting date

"Next run time" is only meaningful relative to some starting point — the calculation for 0 9 * * 1-5 genuinely depends on whether today is a Tuesday or a Saturday. Rather than silently using the current date and time (which would make the same expression produce a different answer depending on when you happened to load the page, and make it impossible to reproduce or share a specific result), this tool requires an explicit starting date. Enter the date and time you actually care about — right now, a future deploy date, or a date from a bug report — and the next five runs are calculated from exactly that point.

Time zone

All run times are shown in UTC. Standard cron expressions have no time zone of their own — they're interpreted relative to whatever time zone the scheduler runs in, and both crontab (typically system local time) and most CI schedulers (typically UTC) vary. Showing results in UTC keeps the tool unambiguous and matches what GitHub Actions, most hosted CI systems and most cloud cron services use by default; adjust manually if your own scheduler uses local time instead.

5-field and 6-field cron

The standard format has five fields: minute, hour, day of month, month, day of week. That is what crontab, GitHub Actions and most CI schedulers use. This tool also accepts a 6-field variant with a leading seconds field (second, minute, hour, day of month, month, day of week), as used by some application schedulers. If you paste a 6-field expression, check that your scheduler really supports it: crontab and GitHub Actions only accept five fields. When both day of month and day of week are restricted, as in 0 9 15 * 1, the job fires when either matches, which is how classic cron behaves.

When something looks wrong

If the expression fails to parse, the exact error from the parser is shown — commonly a field with too few or too many parts, or a value outside its valid range (minutes must be 0–59, for instance). If the plain-English description looks right but the run times seem off, double-check the starting date and remember the results are always in UTC.

Frequently asked questions

Why do I need to enter a "from" date?: Next-run times depend on a starting point. Requiring an explicit date keeps the result reproducible — the same expression and date always produce the same five run times, unlike a tool anchored to "right now."
What time zone are the run times shown in?: UTC, always — the same time zone standard cron uses on most servers and the one GitHub Actions and most CI schedulers run in. Convert manually if your scheduler runs in local time.
Does this support 6-field cron with seconds?: Yes — a 6-field expression is read as second, minute, hour, day of month, month, day of week (for example `30 0 9 * * *` is 09:00:30 every day). Note that crontab and GitHub Actions only accept the 5-field form, so drop the seconds field before using the expression there.
What happens with an invalid expression?: The exact parser error is shown — for example, too few fields or a value out of range for its field — instead of a silent failure.