⏱ Cron Expression Visualizer

By Λ · Updated June 9, 2026 · ~3 min read

Why this exists

Cron expressions are dense. */15 9-17 * * 1-5 is "every 15 minutes between 9 AM and 5 PM, Monday through Friday", but that takes a second to translate in your head and several seconds to verify. The mistake everyone has made: writing a schedule, deploying it, and realizing the next day that it fires at 9 PM instead of 9 AM, or every minute instead of every fifteen. This visualizer shows the next ten runs so you can sanity-check before deploying.

How it computes the next ten runs

The page expands each field into a set of allowed values, honoring comma lists, hyphen ranges, and step syntax, then rolls a clock forward from the next whole minute: non-matching months skip a month, dead days skip a day, wrong hours skip an hour, and the last gap closes minute by minute until ten fire times are collected, each printed with a countdown like "in 3h 42m". The schedule math is ordinary JavaScript executing on this page, so the expressions you test are never transmitted off your machine.

Worked examples

Type */15 9-17 * * 1-5 and the explanation box reads: Runs every 15 minutes of hour 9-17, on Mon through Fri. The last fire each day is 17:45, not 17:00, because a 9-17 range covers the entire 5 PM hour. Or try 0 0 1 * 1 on Tue, Jun 09, 2026: the list opens with Mon, Jun 15 at 00:00, then Jun 22, Jun 29, and Wed, Jul 01 slipping in between Mondays.

The five fields

Standard Unix cron uses five space-separated fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6 where 0=Sunday). The asterisk means "any value". Slashes mean "step": */5 in the minute field means "every 5 minutes". Commas mean "or": 1,15,30 means "at minute 1, 15, and 30". Hyphens mean "range": 9-17 in the hour field means "9 AM through 5 PM inclusive".

The day-of-month / day-of-week gotcha

If you specify both day-of-month and day-of-week, the job runs when either matches (not both). 0 0 1 * 1 runs at midnight on the 1st of every month AND on every Monday, not "the 1st only if it is a Monday". This catches everyone at least once.

What this tool does NOT support

Six-field syntax with seconds. Quartz and Spring use a 6-field variant where the first field is seconds. Tracked on the roadmap but most cron daemons (cron, crontab, anacron, systemd timers) use the standard 5-field form.

Day names and month names. MON, JAN, etc. are valid in many implementations. This tool only accepts numbers for predictability.

Special strings. @hourly, @daily, @reboot are not parsed. Use the equivalent numeric form.

Timezone awareness. The "next runs" are shown in your browser's local timezone. The underlying cron daemon usually runs in the server's timezone, often UTC. If you are scheduling for a server in a different zone, mentally shift the output.

Impossible dates. A schedule like 0 0 30 2 * can never match; the search gives up after a bounded number of steps and the runs list comes back empty rather than erroring.

FAQ

Why does my day-of-month job skip certain months?

An expression like 0 0 31 * * only matches months that contain a 31st; the others are passed over silently.

Are the listed times UTC?

No, they render in your browser's timezone; compare against the server's zone before concluding a job is mis-scheduled.

What triggers the "Could not parse" error?

Anything other than exactly five space-separated fields, or a token that cannot be read as numbers: day names, @daily macros, or a zero step.

Related

The cron parser gives you a single human-readable description. For Unix timestamps, see the timestamp converter.