Cron Expression Parser
Explains a cron expression in plain English and calculates the next run times.
—
0–59—
0–23—
1–31—
1–12, JAN–DEC—
0–7, SUN–SAT (0 and 7 = Sunday)What is a cron expression
Cron is the standard task scheduler on Unix/Linux systems — used in server crontabs, in CI/CD pipelines (e.g. GitHub Actions) and countless automation tools. A cron expression has 5 space-separated fields, always in this order: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–7). Each field accepts a fixed value, an asterisk "*" (any value), a list ("1,15,30"), a range ("9-17") or a step ("*/15", every 15 units) — and any combination of those forms.
Cron's classic gotcha: day-of-month OR day-of-week
When day-of-month and day-of-week are **both** restricted (neither is "*"), cron combines them with OR, not AND — "0 0 1 * 0" runs at midnight on the 1st of every month **or** every Sunday, never "only when the 1st falls on a Sunday". It's the #1 source of confusion for anyone new to cron. When only one of the two fields is restricted, the rule never kicks in — the other, being "*", would always be true anyway.
Sunday is "0" — but "7" also works
The day-of-week field runs 0 through 6 in the most common convention (0 = Sunday, 6 = Saturday, the same value JavaScript's `Date.getDay()` returns), but the cron standard also accepts "7" as a synonym for Sunday, for anyone who thinks of the week as starting on Monday. This tool accepts both forms and always normalizes to "0" internally.
Supported shortcuts and out-of-scope extensions
The classic crontab shortcuts are supported: @yearly/@annually ("0 0 1 1 *"), @monthly ("0 0 1 * *"), @weekly ("0 0 * * 0"), @daily/@midnight ("0 0 * * *") and @hourly ("0 * * * *"). @reboot is recognized, but rejected with its own message — it doesn't represent a time, it runs once at system startup. Extensions from specific schedulers like Quartz/Jenkins (`L` for last day, `W` for nearest weekday, `#` for the Nth occurrence of a weekday in the month, `?` as a wildcard) aren't recognized — this tool covers the classic cron standard (Vixie/POSIX), the most common one in server crontabs and CI/CD.
Why isn't there a timezone selector?
Cron carries no timezone at all — its fields are just numbers, read literally by whatever runs the expression. If your server is on UTC and you want something to run at midnight in your own timezone (say, UTC-3), you work out the offset yourself when writing the expression ("0 3 * * *", not "0 0 * * *"). This tool does exactly what cron itself does: it shows the times literally, without converting anything — the next-run list uses this device's clock as the reference for "now", never a chosen timezone.
Frequently asked questions
Because day-of-month ("1") and day-of-week ("0") are both restricted at the same time — in that case cron combines the two with OR, not AND. See "Cron's classic gotcha", above.
No — cron has no notion of timezone. This tool reads the fields literally, exactly like cron does, and calculates the next runs using this device's clock. See "Why isn't there a timezone selector?", above.
"@reboot" doesn't represent a recurring time — it runs once, at system startup. This tool calculates upcoming runs over time, so that shortcut is out of scope.
Not in this version. Those extensions belong to specific schedulers (Quartz, Jenkins), outside the classic cron standard (Vixie/POSIX) this tool covers — the same one used by Linux server crontabs and most CI/CD tools.
Yes, both forms work and mean the same day. See "Sunday is '0' — but '7' also works", above.
@yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly — each expands to a 5-field expression (see "Supported shortcuts", above). @reboot is recognized, but rejected since it has no associated time.
Not in this version — only the classic 5-field standard (minute, hour, day of month, month, day of week), the most common one in server crontabs and CI/CD.