Are L, W and # supported?

No. Those are Quartz extensions, and this parser rejects them rather than guessing.

Which time zone are the run times in?

Your computer’s, because that is the only clock this page can read. A cron daemon uses the server’s zone, or whatever CRON_TZ is set to in the crontab, so shift the times if your server runs UTC and you do not. Daylight saving is the other trap: a job scheduled inside the hour that spring-forward skips will not run at all that day.

Why does it say no run time exists?

The projection searches five years ahead and then gives up. A combination like 30 February, or 31 April in a month that has no 31st, can never match any date, so there is nothing to show.

What does @reboot do here?

Nothing, it is rejected with an explanation. @reboot fires when the machine boots, so there is no clock schedule to project from it.

Cron Parser

No upload · runs in your browser

Cron expression

Presets

Schedule

At 09:00, on Monday to Friday.

0 9 * * 1-5 · 5 fields · times shown in UTC

Next 5 runs

Reading your clock…

Field breakdown

Minute00

Hour99

Day of month*Every day

Month*Every month

Day of week1-5Monday to Friday

Next run

Then after

Fields

Time zone

UTC

Parsed and projected in your browser, the expression is never uploaded.

How it works

Cron Expression Parser: Plain English and the Next 5 Runs

Paste a crontab line to read it back in plain English and see exactly when it fires next. Ranges, steps, lists, month and day names, seconds fields and @daily shortcuts all parse locally.

What this does

Plain-English reading of a 5-field crontab line, or a 6-field one that starts with seconds
The next five run times in your browser’s own time zone, each with the gap to it
Ranges and lists, plus steps like */15 and a wrap-around range like FRI-MON
JAN–DEC and MON–SUN names, with 7 accepted as Sunday alongside 0
@yearly, @monthly, @weekly, @daily and @hourly expand to the expressions they stand for
A field-by-field breakdown showing what each raw token actually matches

FAQ

Because cron ORs day-of-month against day-of-week whenever both fields are restricted, rather than ANDing them. That expression runs on the 13th of every month and on every Friday, so roughly nine times a month instead of once or twice a year. The AND you expected only appears when one of the two fields is *, at which point the other acts as a plain filter. The plain-English reading here says “or” out loud for exactly this case, and a genuine Friday-the-13th schedule needs a date check inside the job itself.

Keep going