Developer & Tech

Cron Expression Parser

What this does

Translate five-field cron expressions into plain English, validate every field range and list the next scheduled run times.

Enter your details

Runs in your browser

Calculator inputs

How to use it

Using the cron expression parser

  1. 01

    Paste the expression

    Straight from your crontab, Kubernetes CronJob or CI config.

  2. 02

    Read the description

    The plain-English summary catches inverted fields and off-by-one hours instantly.

  3. 03

    Check the next runs

    Concrete upcoming timestamps verify daylight-saving and weekend behavior before deployment.

Good to know

The classic cron gotchas this parser exposes

  • Day-of-month AND day-of-week both restricted → fires when EITHER matches (standard behavior)
  • 0 0 * * * is midnight local on the server, which may be UTC
  • Ranges wrap nothing: 23-2 in hours is invalid, not cyclic
  • Steps need an anchor: */15 starts at the field minimum

Why predicting runs beats eyeballing

DST transitions make “daily at 2:00” fire once, twice or never depending on locale. Scanning actual calendar minutes surfaces those anomalies before production does.

How it's calculated

The math behind this calculator

fields: minute(0-59) hour(0-23) dom(1-31) month(1-12) dow(0-7); syntax: * , - /

Each of the five fields parses into a set of allowed values supporting lists (commas), ranges (dashes) and steps (slashes), with standard Vixie semantics; including the either-side rule when both day-of-month and day-of-week are restricted. Field ranges validate strictly with named errors.

A human-readable description assembles from the parsed sets, then a minute-by-minute scan over the next 366 days collects the upcoming run times against your local clock so you can confirm the schedule means what you think it means.

Assumptions & limitations

  • Standard five-field crontab syntax; seconds-level crons are not modeled.
  • @-macros and name forms (JAN, MON) are rejected rather than guessed.
  • Run predictions use your device time zone; servers often run cron in UTC.

Worked example

* * * * * matches every minute of every day, so the description reads simply “Every minute” and the next run lands within sixty seconds of now.

FAQ

Frequently asked questions

Why is @daily rejected?
Macros are shorthands for fixed expressions; @daily is just 0 0 * * *. Writing it out keeps validation honest about what actually runs.
What time zone do the next runs use?
Your device’s current zone. Production cron daemons frequently run UTC; convert accordingly before comparing.
Is 7 accepted for Sunday?
Yes; day-of-week treats 0 and 7 equivalently, per POSIX crontab convention.
How far ahead does the search look?
366 days. A schedule matching no minutes in that window (like February 30th) reports an explicit error instead of pretending.

Keep exploring

Related calculators