Cron Expression Parser

How Cron Expression Parser Works

What is Cron?

Cron is the scheduling system used by Unix-like operating systems to run a command automatically at a fixed time, date, or interval — nightly backups, hourly cache refreshes, monthly billing runs, and countless other recurring jobs. Rather than a human remembering to run something, a crontab entry describes exactly when it should happen, and the system runs it unattended. This tool explains what a cron expression means and previews when it will next fire — it doesn't schedule or run anything itself.

Cron Syntax

A standard cron expression is five space-separated fields, each describing one part of the schedule:

minute  hour  day-of-month  month  day-of-week
  *      *         *         *         *

Each field accepts a number, a wildcard, a list, a range, or a step value (explained below). A job runs only when the current moment matches every field at once — with one notable exception for day-of-month and day-of-week, covered in Common Mistakes.

The Five Fields Explained

Wildcards

An asterisk (*) means "every value is allowed" for that field. * * * * * means every minute of every hour of every day — the job runs once a minute, continuously.

Lists

A comma-separated list runs on each listed value: 0,15,30,45 * * * * runs at minutes 0, 15, 30, and 45 of every hour — four times an hour.

Ranges

A hyphen defines an inclusive range: 1-5 in the day-of-week field means Monday through Friday. 15 10 * * 1-5 runs at 10:15 AM UTC on every weekday.

Step Values

A slash defines an interval: */5 in the minute field means every 5 minutes (0, 5, 10, 15…). Steps can also apply to a range, like 0-30/10 for every 10 minutes between the top of the hour and the 30-minute mark.

Common Mistakes

• Assuming day-of-month and day-of-week combine with AND. When BOTH fields are restricted (not *), cron treats them as OR, not AND — 0 0 1,15 * 1 runs at midnight on the 1st, the 15th, and every Monday, not only when both conditions are true on the same day. This surprises almost everyone the first time they hit it.
• Confusing minute and hour order. The first field is minute, the second is hour — 30 9 * * * is 9:30 AM, not 30 minutes past 9 seconds or 9:30 PM.
• Using a 6 or 7-field Quartz-style expression. Some schedulers (like Java's Quartz) add a seconds field at the start and an optional year field at the end. Standard cron doesn't support either — this tool sticks to the classic 5-field format and will tell you clearly if it detects extra fields.
• Forgetting cron has no built-in time zone. A cron daemon runs in whatever time zone its host system is configured for — see UTC vs Server Time below.

UTC vs Server Time

A cron expression by itself carries no time zone information — 0 9 * * * means "9 o'clock" in whatever zone the scheduler is running in. This tool always computes and displays upcoming run times in UTC, since that's the only zone-independent way to preview a schedule without knowing where it will actually be deployed. When you configure the real job, check what time zone your scheduler or server uses — a job meant for 9 AM local time will fire at the wrong hour if the server is UTC and no adjustment is made.

Related Tools

Working with schedules and timestamps often overlaps with other developer utility tasks: convert between epoch and calendar time with the Unix Timestamp Converter, validate a schedule string's shape with the Regex Tester, inspect a token's time-based claims with the JWT Decoder, reformat a JSON job definition with the JSON Formatter, or fingerprint a config file with the Hash Generator.