Developer Runs locally Ready to use Built-in examples No tracking

Cron Expression Parser

Parse 5-field cron expressions with steps, ranges, names and @macros, read each field in plain language, and see the next 5 execution times in your local timezone.

A cron expression describes a scheduled job in five fields — minute, hour, day of month, month, day of week — each supporting the wildcard *, comma-separated lists, hyphenated ranges, slash steps, and macros such as @daily. This parser reads each field back in plain language and computes the next five run times, which answers the question of whether the expression really does fire at midnight every day.

The trap most often hit is the semantics when the day-of-month and day-of-week fields are both restricted: by the Vixie cron standard that is an OR rather than an AND, so 0 0 13 * 5 runs on the 13th and on Fridays, not only when the 13th happens to be a Friday. Run times are computed in the server's local timezone, so a cross-timezone deployment needs the container or system timezone confirmed first.

—
—
—
—
—
—

How to use

  1. Paste the five-field expression, or a macro such as @daily.
  2. Read each field in plain language.
  3. Check the next five run times.
  4. Watch the OR semantics when day-of-month and day-of-week are both set.

How it works

The five-field order

The five fields, left to right: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6, 0 = Sunday). Each supports * (any), comma lists, hyphen ranges and slash steps (*/15 = every 15 units from the start).

Supported syntax

Beyond numbers, day-of-week accepts sun mon tue wed thu fri sat and months accept jan–dec (any case); writing 7 for Sunday equals 0. The macros @yearly (@annually), @monthly, @weekly, @daily (@midnight) and @hourly expand automatically into their five-field equivalents.

How the next run time is computed

Next run time starts from the following minute and matches all five fields minute by minute, scanning at most two years ahead. When both day-of-month and day-of-week are restricted, Vixie cron semantics apply: matching either one triggers a run ("13th and Friday" really means "13th OR Friday").

Code example

Crontab Common patterns 

# Every day at midnight
0 0 * * *

# Business days at 9:30
30 9 * * 1-5

# Every 15 minutes
*/15 * * * *

# 2 a.m. on the 1st of each month
0 2 1 * *

# Macros
@daily    # same as 0 0 * * *
@weekly   # same as 0 0 * * 0

Shell Listing and debugging 

# List the current user's scheduled jobs
crontab -l

# With systemd timers, check the next trigger time
systemctl list-timers

# Tip: cron has a minimal environment — use absolute paths and set PATH explicitly in scripts

FAQ

What's the field order of five-field cron?

Minute, hour, day, month, weekday — 30 8 * * 1-5 means 08:30 on weekdays. Quartz uses six fields (a seconds slot, weekdays from 1); this tool parses Linux crontab's five-field form, so strip the seconds and remap weekdays for Quartz expressions.

When both day and weekday are specified, how does it run?

Standard (Vixie) semantics are OR: with neither field a *, matching either one runs the job. So 0 0 13 * 5 means "13th OR Friday", not "13th and Friday". The tool flags this combination explicitly to prevent misconfiguration.

What do macros like @daily mean?

@yearly (@annually) = 0 0 1 1 * (Jan 1 midnight); @monthly = 0 0 1 * * (1st midnight); @weekly = 0 0 * * 0 (Sunday midnight); @daily (@midnight) = 0 0 * * * (daily midnight); @hourly = 0 * * * * (top of every hour).

What about impossible expressions like Feb 30?

0 0 30 2 * never matches (February has at most 29 days). If two years of scanning find no match, the tool reports "no match within two years" rather than waiting silently — handy for catching config mistakes.

Which timezone is used?

Your browser's local timezone — matching how a server crontab runs on the system timezone. If the server runs UTC while you're at UTC+8, shift the hour field by 8 or verify on a machine in the server's timezone.

Are 0 and 7 the same in the weekday field?

Yes, both mean Sunday. 0 is standard; some implementations accept 7 as an alias — this tool supports both and normalizes to 0. Monday through Saturday are 1–6.

Does it support second-level scheduling or @reboot?

No. Linux crontab's finest granularity is the minute; second-level scheduling needs systemd timers, Quartz or a dedicated scheduler. @reboot fires once at boot with no fixed time, so "next run" can't be computed — it's outside parsing scope.