Cron Expression Parser

Read a cron line in plain English and see exactly when it will next fire — including the day-of-week rule almost everyone gets wrong.

Next runs

Common expressions

🔒 Runs entirely in your browser — nothing you type is uploaded or stored on a server.

Paste a cron expression and this page tells you what it means in a sentence, breaks down each of the five (or six) fields, and lists the next times it will actually fire. Reading the schedule off the real next-run times is the fastest way to catch a job that was meant to run nightly and is quietly running every minute.

Also on Txtset: convert a Unix timestamp by hand · count down to one of those times.

The rule most people get wrong, and the reason a job fires more often than expected: when the day-of-month and day-of-week fields are both restricted, cron takes the union of the two, not the overlap. 0 0 1 * 1 does not mean “the 1st, if it is a Monday” — it means “the 1st of every month, and every Monday”, which is roughly five times a month. This parser follows the POSIX behaviour, says so in the description, and its preview shows you the extra days.

It understands the full syntax you meet in practice: ranges (9-17), steps (*/15, 0-30/5), lists (1,15,30), three-letter month and day names (JAN, MON), the Quartz-style ?, wrapping ranges like FRI-MON, both Sunday spellings (0 and 7), the @daily-style shorthands, and the 6-field form where the first field is seconds.

Times can be shown in your local time zone or in UTC, and the difference is not cosmetic: a server running on UTC will fire 0 3 * * * at 03:00 UTC regardless of where you are, and a job scheduled in local time drifts by an hour twice a year when daylight saving moves. Everything is computed in your browser; nothing you type is uploaded.

How to use

  1. Type or paste a cron expression, or click one of the common examples below the results.
  2. Read the plain-English description and the per-field breakdown.
  3. Check the next run times — that list is the real answer to “when does this fire?”.
  4. Switch between your local time and UTC if the job runs on a server in another zone.

Examples

*/15 9-17 * * 1-5
Every 15 minutes between 09:00 and 17:00, Monday to Friday.
0 0 1 * 1
The 1st of every month and every Monday — the union rule in action, not “only when the 1st is a Monday”.
@daily
Shorthand for 0 0 * * * — midnight every day.

Frequently asked questions

What do the five fields mean?
In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–7, where both 0 and 7 mean Sunday). A sixth field is sometimes added at the front for seconds, which this parser detects automatically.
Why does my job run on days I did not expect?
Almost certainly the day-of-month / day-of-week union rule. If both fields are set to something other than *, cron fires when either matches, not when both do. To get “only on Mondays”, leave day-of-month as *.
What does <code>*/15</code> mean?
Every 15th value in that field, starting at the lowest — so in the minute field it is minutes 0, 15, 30 and 45. Note that it steps through the field's range, not from “now”: */15 in the hour field is 00:00, 03:00… not “every 15 hours from whenever you deployed”.
Which time zone are the next runs in?
Whichever you pick. The default is your device's local time zone; switch to UTC if the job runs on a server set to UTC, which most of them are. Getting this wrong is the second most common cause of a job firing at a surprising hour.
Does it handle <code>@daily</code> and <code>@reboot</code>?
It expands @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly. @reboot is recognised but has no schedule to preview — it runs once when the machine starts.
Why does my expression say it never runs?
Usually an impossible date, such as 0 0 30 2 * — the 30th of February. The parser looks thirty years ahead and tells you rather than showing an empty list.
Is anything sent to a server?
No. The parsing and the next-run calculation happen entirely in this page.