Cron Expression Reader — Decode Cron to Human-Readable Text
Enter a standard 5-field cron expression and instantly see a plain-English description of the schedule, plus the next 10 execution times. Understand exactly when your cron jobs will run. 100% client-side — nothing leaves your browser.
What does a cron expression mean? A cron expression is five space-separated fields — minute, hour, day of month, month, day of week — that together describe when a scheduled job runs. Each field holds a single number, a range such as 1-5, a list such as 1,3,5, a step such as */10, or * for every value. The job fires at any minute where all five fields match the clock.
How to Use the Cron Expression Reader
- Enter the five fields — Type the expression in the order minute hour day-of-month month day-of-week, separated by spaces. Parsing runs on every keystroke, so there is no button to press — an expression with four or six fields is rejected immediately with the count it actually found.
-
Read the schedule sentence — The Schedule box rewrites each field as a phrase, so
*/5 * * * *reads as "every 5 minutes". Treat it as a summary rather than a contract: in the month and day-of-week fields it names the first value of a range instead of spelling the range out. - Check the next 10 run times — The list underneath is the authoritative answer. It is built by stepping forward one minute at a time from the current clock and keeping the first ten instants that satisfy all five fields, searching up to a year ahead.
-
Shift the clock if the server is not on your time — The timezone offset is how many hours ahead of your own clock the scheduling machine runs. Enter
2for a server two hours ahead; the run list stays in your local time, so you can see where each execution lands on your day. -
Start from a preset — The three buttons load
*/5 * * * *,0 9 * * 1-5and0 0 1 * *. They are a quick way to see the output shape and a working base you can edit one field at a time. - Share or bookmark the link — The expression and the offset are written into the page URL as you type, so the address bar always reflects what you are looking at. Copy it into a pull request or a runbook and the reader opens with the same schedule loaded.
How Cron Expressions Are Parsed
Cron has scheduled jobs on Unix systems since the 1970s, and the five-field syntax popularised by Vixie cron —
the implementation behind crontab on most Linux distributions and on macOS — is still the format
nearly every scheduler accepts. The fields are read left to right, and each one narrows a different part of the
clock and calendar:
This reader splits your input on whitespace and expands every field into the explicit set of numbers it stands
for. */15 in the minute field becomes 0, 15, 30 and 45; 1-5 in the day-of-week field
becomes 1, 2, 3, 4 and 5; a bare 0 stays a single value. Once all five sets exist, deciding whether
a particular minute is a run time is just a membership test — its minute, hour, day, month and weekday all have
to appear in their respective sets.
Rather than solving for the next match algebraically, the tool walks forward one minute at a time from the
current clock and tests each candidate, stopping once it has collected ten hits or has scanned a full year
(525,600 minutes) without finding them. That brute-force scan is why an impossible expression such as
0 0 30 2 * — the thirtieth of February — reports no upcoming runs rather than hanging or guessing
at what you meant.
What Each Field Accepts
| Position | Field | Values | Example |
|---|---|---|---|
| 1 | Minute | 0 – 59 | 30 — half past the hour |
| 2 | Hour | 0 – 23 (24-hour clock) | 0 — midnight |
| 3 | Day of month | 1 – 31 | 1 — the first of the month |
| 4 | Month | 1 – 12 | 12 — December |
| 5 | Day of week | 0 – 6, Sunday first | 1-5 — Monday to Friday |
Every value here is numeric. The three-letter abbreviations some crons accept in the month and day-of-week
fields — JAN, DEC, MON, SUN — are rejected by this parser,
as are the shorthand macros such as @daily and @reboot, the six-field variants
that add seconds or a year, and the Quartz extensions L, W, # and
?. Write the numbers instead: 0 6 * * 1 rather than 0 6 * * MON.
Many crontabs treat 7 as a second spelling of Sunday. This reader accepts 7 without complaining but matches weekdays against JavaScript's 0–6 numbering, so 0 0 * * 7 on its own finds no upcoming runs. Use 0 for Sunday.
Operators
| Symbol | Name | Meaning | Example |
|---|---|---|---|
* | Wildcard | Every value the field allows | * * * * * — every minute |
, | List | Several specific values | 0 8,12,17 * * * — 08:00, 12:00 and 17:00 |
- | Range | Every value between two bounds, inclusive | 0 9 * * 1-5 — 09:00 on weekdays |
/ | Step | Every nth value counting up from the start | */20 * * * * — at :00, :20 and :40 |
A step may start from a number instead of *: 5/15 in the minute field means 5, 20, 35
and 50. What this reader does not implement is a step applied to a range, the 1-5/2 form. Because
that combination matches neither the step pattern nor the range pattern, only the leading number survives
parsing — 1-5/2 quietly becomes 1. Write the values out as a list, 1,3,5,
and the schedule and the run list will agree.
The Day-of-Month and Day-of-Week Trap
The single most misread part of cron is what happens when fields three and five are both restricted. Under Vixie
cron and the crontabs derived from it, day of month and day of week are combined with or, not
and: if neither field is *, the job runs whenever either one matches. So
0 0 13 * 5 on a real Linux box fires at midnight on the 13th of every month and at
midnight every Friday — not only on Friday the 13th.
This reader takes the stricter reading and requires all five fields to match, so the same expression lists only
Friday the 13th. Whenever exactly one of the two day fields is * — which covers the overwhelming
majority of real crontabs — the two interpretations are identical and the run list is exactly what your server
will do. The divergence only appears when you pin a date and a weekday at the same time, and the safest habit
is to avoid that combination entirely: schedule the monthly run and the weekly run as two separate crontab lines
so there is nothing left to interpret.
Cron also has no memory. If the machine is asleep, powered off or overloaded when a scheduled minute passes, standard cron does not run the job late — the occurrence is simply missed. Systems that catch up afterwards, such as anacron or a job queue with retries, are doing something cron itself never promised.
Common Cron Patterns
Most production schedules are variations on a handful of shapes. These all parse in this reader, and you can paste any of them in to see the exact timestamps they produce over the coming days.
| Expression | When it runs |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every five minutes, aligned to :00, :05, :10 and so on |
0 * * * * | Once an hour, exactly on the hour |
0 3 * * * | 03:00 every day |
30 2 * * 0 | 02:30 every Sunday |
0 9 * * 1-5 | 09:00 Monday to Friday |
0 0 1 * * | Midnight on the first of every month |
0 22 * * 6 | 22:00 every Saturday |
0 0 1 1 * | Midnight on 1 January |
15 14 1 * * | 14:15 on the first of every month |
Why a Step Is Not the Same as an Interval
A step divides the field it sits in; it does not measure elapsed time from the last run. */20 in
the minute field means minutes 0, 20 and 40 of every hour, which happens to be a clean twenty-minute rhythm.
*/40 means minutes 0 and 40 — and then the hour rolls over and the count restarts, so the gap
between the run at :40 and the next one at :00 is twenty minutes, not forty. Any step that does not divide
evenly into 60 produces this short interval at the boundary. If you need a true fixed interval that does not
reset, cron is the wrong tool: use a timer, a queue delay or a systemd timer with OnUnitActiveSec.
Frequently Asked Questions
A cron expression is the schedule half of a crontab line: five space-separated fields giving the minute, hour, day of month, month and day of week on which a command should run. Each field is a number, a range, a comma-separated list, a step or * for every value. The scheduler checks the expression once a minute and runs the command whenever the current time satisfies it.
Standard five-field numeric cron with wildcards (*), lists (1,3,5), ranges (1-5) and steps (*/5 and 5/15). It does not accept month or weekday names such as JAN and MON, the @daily and @reboot macros, six-field formats that add seconds or a year, or the Quartz extensions L, W, # and ?. Convert names to numbers and those expressions parse fine.
Your browser's local timezone, since the calculation uses the JavaScript Date object. The offset field is not a UTC selector — it is the number of hours the scheduling machine is ahead of you. Leave it at 0 when the server keeps the same clock as your laptop. Set it to 2 when the server is two hours ahead, and the list will show the local times at which its schedule fires.
Vixie cron uses OR when both fields are restricted, so 0 0 13 * 5 runs on the 13th of every month and on every Friday. This reader requires every field to match, so it lists only Friday the 13th. Whenever one of the two day fields is * — true of almost every real crontab — both readings agree exactly. Split date-based and weekday-based schedules into separate lines to sidestep the ambiguity.
No. Parsing and the run-time search both happen in JavaScript inside your tab, and no request carries your input. The expression and offset are written into the page URL so the view can be bookmarked or shared, which is worth remembering if the expression itself is sensitive — clear the field before copying the address.
No. A step divides its field rather than counting from the last run, so */5 means minutes 0, 5, 10 … 55 of every hour, on fixed marks. That only feels like an interval because 5 divides evenly into 60. */40 gives you :00 and :40, then the hour restarts, leaving a 20-minute gap. For a genuine elapsed-time interval you need a timer or a queue delay, not cron.
The sentence builder labels the month and day-of-week fields from the first number it sees, so a range such as 1-5 is summarised as its opening value. The next-run list does not share that shortcut: it expands the full range and is correct. When the sentence and the timestamps seem to disagree, trust the timestamps.
Use this reader when you already have an expression — from a crontab, a CI config or a Kubernetes CronJob — and need to know what it does. Use the Cron Builder when you are starting from a schedule in your head and want the syntax generated for you. The Cron Cheat Sheet is the fastest route when you just need to recall an operator.
Use Cases
Reviewing a Crontab Change
A colleague's pull request changes a backup job from 0 2 * * * to 0 2 */3 * *. Paste both into the reader and compare the next ten timestamps before approving, so the review turns on dates rather than on a guess about what the step does.
Auditing a CI or Kubernetes Schedule
Copy the schedule value out of a GitHub Actions workflow or a Kubernetes CronJob manifest and confirm it does not collide with a nightly deploy window before the pipeline runs unattended for a month.
Explaining a Missed Run
A report that was supposed to arrive on Monday morning never landed. Reading the schedule shows the expression pins a day of the month as well as a weekday, so the two conditions rarely coincide — the job did not fail, it was never due.
Coordinating Across Timezones
Your batch server runs on UTC while you work three hours ahead of it. Set the offset and the run list re-expresses the server's schedule on your own clock, so you know whether the overnight import finishes before your standup.
Learning the Syntax
Change one field at a time — turn 0 9 * * * into 0 9 * * 1-5, then into 0 9,17 * * 1-5 — and watch the timestamps move. Seeing the effect of a single character is faster than reading the manual page twice.
Spreading Load Off the Hour
Ten services all scheduled at 0 * * * * hammer a shared database on the hour. Trial expressions such as 7 * * * * or */10 * * * * here to stagger them, and confirm the new marks before editing production crontabs.