Cron Expression Parser, Explained

After reading this you can read any 5-field cron expression at a glance, predict its next runs by hand, and avoid the three scheduling bugs that fire jobs at the wrong time.

What a cron expression is

A cron expression is a compact schedule. It has five fields separated by spaces: minute, hour, day-of-month, month, and day-of-week. A daemon reads the fields once a minute and runs the job when all of them match the current time.

Here is the hook. Read this line:

Left to right: minute 0, hour 9, any day-of-month (*), any month (*), day-of-week 1-5 (Monday through Friday). So it means "at 09:00 on weekdays." One line, five numbers, one clear meaning. The trouble starts when the fields interact, which is why a parser that previews real timestamps beats reading the syntax in your head.

When to use it, and when a real scheduler is better

Reach for cron when a task repeats on a wall-clock pattern: nightly backups, hourly cache warmups, a weekly report at 07:00 Monday. Cron is stateless. It does not track whether a run succeeded, and it does not retry. It just checks the clock every minute.

Do not use cron for these cases. If you need a job to run 30 minutes after another finishes, cron cannot express that; it only knows absolute times. If runs must not overlap, cron will happily start a second copy while the first is still going. And if you need sub-minute timing, cron cannot help: the smallest field is one minute.

The five fields and their ranges

Each field accepts a number, a range, a list, a step, or the wildcard *. The valid ranges are fixed:

Day-of-week is the one to watch. Both 0 and 7 mean Sunday, so the field really covers 8 tokens for 7 days. Monday is 1, Saturday is 6.

The four operators

Wildcard *

Every value in the field's range. In the minute field it means all 60 minutes.

List a,b,c

Any of the listed values. 0,30 in minutes means minute 0 and minute 30.

Range a-b

Every value from a to b inclusive. 1-5 in day-of-week is Monday through Friday.

Step a/n or */n

Every nth value. */15 in minutes is 0, 15, 30, 45. 10-30/5 is 10, 15, 20, 25, 30.

How the next run is computed

To find the next fire time, walk forward from "now" one minute at a time and stop at the first minute where the match condition holds. The condition is a logical AND across four of the five fields, with one exception:

Here M_{min} is true when the current minute is in the minute field's set, and likewise for hour, month, day-of-month, and day-of-week. Minute, hour, and month are AND-ed. Day-of-month and day-of-week are combined with OR when both are restricted, which is the POSIX quirk explained below.

The step operator expands to a set before matching. For */15 the minute set is \{0, 15, 30, 45\}, computed as every value v in 0-59 where v \bmod 15 = 0. A cron with all-wildcard fields (* * * * *) matches every minute, so it fires 1440 times a day.

Reading and interpreting the results

The parser gives you two things: a field-by-field English gloss, and a list of upcoming timestamps. Read the gloss first to confirm the intent, then check the timestamps to confirm the effect. They should agree. If the gloss says "every 15 minutes" but the runs are an hour apart, you have a typo, probably a comma where you meant a slash.

Count the runs. A schedule that should fire hourly (0 * * * *) produces 24 timestamps per day. If you see 1440, you left the minute field as * by mistake, and the job runs every minute. The run count is the fastest sanity check you have.

Common mistakes

The day-of-month and day-of-week OR is the mistake that surprises everyone. When you restrict both fields, cron fires when either matches, not both. Take 0 0 13 * 5. You might read it as "midnight on Friday the 13th." It actually means midnight on the 13th of every month AND midnight on every Friday. In a normal month that is roughly 4 Fridays plus one 13th, so around 5 fires, not the 1 or 2 you expected. To get only Friday the 13th you cannot express it in standard cron alone; you run a daily job and check the date inside the script.

The second mistake is timezone. Cron runs in the server's timezone. A job at 0 9 * * * fires at 09:00 on the server clock. If your laptop is in a zone 6 hours behind the server, that run lands at 03:00 your time. Confirm the server's zone before you trust a morning schedule.

The third is the off-by-one in day-of-week. Sunday is both 0 and 7, and Monday is 1. People coming from languages where Monday is 0 write 0 expecting Monday and accidentally schedule Sunday.

Related tools

Cron fires produce timestamps, and you often need to convert them. To turn a fire time into Unix time or read a log timestamp back into a date, use the Unix Timestamp Converter. If a log gives you a bare number and you cannot tell whether it is seconds or milliseconds, the Epoch Millis vs Seconds Detector settles it. And when a scheduled job needs a unique run ID, the UUID / ULID / Nano ID Generator produces sortable ULIDs and UUID v7 that carry their own timestamp.

Related tools

Crontab Builder

Build a cron expression with dropdowns, no syntax needed.

UUID / ULID / Nano ID Generator

Generate UUID v4/v7, ULID and Nano ID — in bulk.

Unix Timestamp Converter

Unix time ↔ human date, any unit, any timezone.

ID Decoder (UUID, ULID, ObjectId, Snowflake)

Auto-detect ID format; decode timestamps in bulk.

Epoch Millis vs Seconds Detector

Paste a numeric timestamp, learn its unit and value.

Base64 / URL / HTML Encoder-Decoder

Encode and decode Base64, hex, URL percent-encoding and HTML entities — with auto-detect, bulk lines and file drop.