Cron Expression Parser & Builder

Build cron expressions and see their next run times explained.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Reads a five-field crontab expression, states in plain English when it fires, and lists the next five times it would actually run — so you can check a schedule against real dates rather than against your own reading of the fields.

How to use it

1Type the expression: minute, hour, day-of-month, month, day-of-week. Numbers, *, ranges (1-5), lists (1,6) and steps (*/15) are understood; names such as MON, the @daily shorthand and six-field Quartz strings are not.
2Read the plain-English description directly beneath the input.
3Check the Next 5 Run Times list, computed from your own machine's clock and timezone — servers usually run cron in UTC, so expect an offset.

Example

Input: 0 0 13 * 5
Output: At 00:00, day-of-month 13, day-of-week 5 — and a run list carrying both the 13th of the month and every Friday

When day-of-month and day-of-week are both restricted, cron combines them with OR, not AND. This expression fires at midnight on every 13th and on every Friday — not only on Friday the 13th. The run list catches that, and it is the part to trust: when an expression is more elaborate than the phrasing rules cover, the description falls back to reciting the raw fields while the list stays exactly right. Two other traps. Sunday is 0 here and only 0, where plenty of crontabs also accept 7 — a 7 in the last field is refused as out of range. And an expression that can never fire, such as 0 0 30 2 *, returns 'No upcoming run found in a reasonable timeframe' rather than an empty list, because the search gives up after three million minutes, a little under six years ahead.

What happens to your data

Parsing and the next-run search happen in the page using your device clock, so the expression is not sent anywhere and no schedule is saved. Each field is expanded into the set of values it permits and the search then steps a Date forward a minute at a time until five matches turn up — which is why the times shown sit in your timezone rather than the machine the job will really run on.

Last updated August 2026

Someone has left a line like 0 3 * * 1 in a crontab and you need to know when it actually fires — before a deploy touches it, or after an overnight job that was meant to have run did not. Reading the five fields by eye works fine until one of them holds a comma or a slash, and then most people guess.

Work out first which dialect you are holding, because they look alike and are not. Classic crontab — the kind on a Linux box, in a Kubernetes CronJob, in most hosting panels — is five fields: minute, hour, day-of-month, month, day-of-week, and that is the shape read here. Quartz, Spring's scheduler and AWS EventBridge use six or seven fields instead, with a leading seconds column and extra characters such as ?, L and # that classic cron knows nothing about. Feed one to the other and every value shifts a whole column.

The floor of the format is one minute, and there is no way to say every ninety minutes, because each field states which values match rather than how long to wait. That is also where the commonest misreading comes from. A step such as */7 in the minute field is not a job every seven minutes: it matches 0, 7, 14 and so on up to 56, then restarts at the top of the next hour, leaving a four-minute gap across the boundary. Steps are only even when they divide the field evenly — */5, */15 and */30 do, */7 and */25 do not.

How it works

Toolvore expands each of the five fields into the full set of values it permits — an asterisk into every value in range, 1-5 into five of them, */15 into four — and then walks a clock forward from the following minute, testing each candidate against all five sets until five matches have turned up. That is why an expression no calendar can satisfy has to be searched for rather than spotted: the arithmetic never proves impossibility, it only runs out of patience. Two places where it parts company with a real crontab are worth knowing before you trust a result. A step written on a bare number, such as 5/2 in the minute field, is read here as the single value 5, where Vixie cron reads it as 5 onwards in twos to the end of the field. And a range that wraps past the end of a field — Friday to Monday written as 5-1 — is refused as a range whose start is greater than its end, rather than wrapping round the week the way some implementations allow. In both cases the description and the run list agree with each other, and not with the machine that will run the job.

Common use cases

Checking an inherited crontab line before a deploy touches it
Confirming a nightly backup runs on the nights you think it does
Working out why a report arrived at the wrong hour
Sanity-checking a Kubernetes CronJob schedule before applying the manifest
Reading a schedule out of someone else's Terraform or Ansible file
Checking a monthly billing job in the week before it matters

Frequently asked questions

What do the five fields in a cron expression mean?＋

Left to right: minute 0 to 59, hour 0 to 23 on a 24-hour clock, day-of-month 1 to 31, month 1 to 12, and day-of-week 0 to 6. Those are the ranges enforced here, and a value outside one is named and refused rather than quietly clamped. Each field takes an asterisk for every value it can hold, a single number, a comma-separated list, a hyphenated range, or a step written with a slash — and those combine inside one field, so 1-5/2 in day-of-week selects Monday, Wednesday and Friday. Read that way, 30 9 * * 1-5 is half past nine on weekdays and 0 0 1 * * is midnight on the first of every month.

Is */15 the same as 0,15,30,45?＋

Identical. Both expand to the same four minutes, as does 0-59/15, and nothing downstream can tell which spelling you used, because the expression becomes a set of matching values before anything else happens to it. Where the spellings stop being interchangeable is when a step rides on a range rather than an asterisk, since counting then begins at the start of that range instead of at zero. 5-59/15 gives 5, 20, 35 and 50; 15-59/15 gives 15, 30 and 45 with nothing at the top of the hour at all. If a step-based schedule fires at times you did not expect, that offset is usually the reason.

Why does my cron line have six fields instead of five?＋

Two quite different causes, with different fixes. Lines in /etc/crontab and in files under /etc/cron.d carry an extra column naming the user the command runs as, sitting between day-of-week and the command itself; a personal crontab opened with crontab -e has no such column. The other cause is a Quartz-style expression — Spring, several Java schedulers, AWS EventBridge — where the leading field is seconds. A five-field reader reports the count it found and stops rather than guessing which of the two you meant. Strip the username or the seconds column to suit, then check the result, because an off-by-one column turns minutes into hours.

What do @daily, @hourly and @reboot mean?＋

They are shorthands that most cron implementations accept in place of the five fields. @yearly and @annually mean 0 0 1 1 *, @monthly is 0 0 1 * *, @weekly is 0 0 * * 0, @daily and @midnight are 0 0 * * *, and @hourly is 0 * * * *. Write the equivalent out in full wherever something refuses the shorthand. @reboot is the odd one out: it fires once when cron itself starts, which is an event rather than a time, so it has no five-field form. Worth knowing that @daily puts every job across a fleet on the same minute, and a scattered minute spreads that load.

How do I schedule a job on the last day of the month?＋

Classic cron has no last-day marker — the L that Quartz and some other schedulers accept is not part of it. Two approaches work. If the job can run at the start of the following month instead, 0 2 1 * * is the simple answer and sidesteps the problem. If it truly must land on the last day, schedule it every evening from the 28th with 0 23 28-31 * * and have the command exit immediately unless tomorrow is the first, which date can answer in a one-line test. The day-of-month field accepts up to 31 whatever the month, so short months skip the dates that do not exist.

What happens to a cron job when the clocks change?＋

On a machine keeping local time, an hour vanishes in spring and repeats in autumn, and cron has to decide what to do with jobs inside it. Implementations differ: Vixie cron treats a job with a fixed hour differently from one with a wildcard, running the skipped ones once after the jump and suppressing duplicates in the repeated hour, while other schedulers do neither and you get a missed run or a double run. The reliable fix is to keep servers on UTC and do the timezone arithmetic where the output is read. The run list here steps an ordinary date forward a minute at a time on your own machine, so it follows whatever your local clock does.

My cron job does not run — what should I check?＋

Once the schedule itself is confirmed, the causes cluster in the environment rather than the timing. Cron runs commands with a minimal environment and does not read your shell profile, so PATH is short — give absolute paths to the interpreter and to the script. A percent sign in a crontab line means a newline and has to be escaped with a backslash, which catches anyone putting a date format into a filename. The file needs a trailing newline after the last entry. Output is mailed rather than displayed, so redirect stdout and stderr into a log and read that. And check you edited the crontab belonging to the user the job runs as.

Is my cron expression sent anywhere?＋

Nowhere. The parsing, the plain-English description and the search for upcoming runs are one client-side function running in the tab you have open: there is no network request behind it, no server route to send an expression to, and nothing written to storage. The expression lives in the page's own state and no further, so a reload returns the box to its default of */5 * * * * with no record of what you typed before. The clock it reads is your device's, which is a privacy point as much as a correctness one — nothing needs to know where you are in order to answer the question.