Cron Next Run Calculator

Paste a 5-field POSIX cron expression and the calculator returns the next five times it will fire in UTC. The parser is the open-source cron-parser library, the same engine used by node-cron, Bull, BullMQ, and most Node-based job-runners — so the output matches what your application would actually do at runtime, not just what the man page implies. No expression is sent to a server: parsing happens in your browser. For schedule planning across zones, pair the result with the world clock; for one-off countdowns to a single cron firing, drop the result into the days-from-today page.

Common use cases

• Verifying a scheduled job before deploying. You wrote `0 2 * * 0` and want to confirm it fires at 02:00 UTC every Sunday before you push to prod. The calculator shows the next five Sunday firings; if the dates look wrong, your expression is wrong. Saves a 15-minute round-trip of "deploy, wait a week, see what happens".
• Debugging a job that did not fire. A job was supposed to run last Wednesday but did not. Plug the expression into the calculator with `from` set to the start of that week — if Wednesday is missing from the next-five list, the expression itself is the bug. The most common cause is the day-of-month / day-of-week OR-semantics gotcha (covered in the edge cases below).
• Migrating from Quartz to POSIX cron. Quartz uses a 6-or-7-field format with seconds and an optional year; POSIX uses 5 fields. When porting jobs from Spring/Quartz to a Linux crontab or to BullMQ, paste the new 5-field expression here to confirm it still fires when expected before swapping over.
• Capacity planning around batch windows. You need to know when the next 10 nightly ETL runs will land so you can pre-provision compute. Bump the count and read off the times. Combine with the days-from-today page to convert each firing into a wall-clock date.

How it works

cron-parser tokenises the expression into five fields (minute, hour, day-of-month, month, day-of-week), validates each against its allowed range and step/range/list syntax, then walks forward from the supplied "from" date one minute at a time, emitting a hit whenever every field matches. The walk is bounded — invalid expressions throw immediately rather than spinning forever. All times are computed and returned in UTC; the calculator does not apply your local timezone, because cron expressions in a Linux crontab are evaluated in the server's TZ (which is rarely your laptop's TZ) and showing UTC keeps the answer unambiguous.

Worked examples

Edge cases & gotchas

• Day-of-month and day-of-week are OR, not AND. POSIX cron is famously surprising here: if BOTH day-of-month and day-of-week are restricted (neither is `*`), the job fires when EITHER matches. So `0 0 1 * 1` fires on the 1st of every month AND on every Monday — not "the 1st, but only if it is a Monday". To restrict to Mondays-that-are-the-1st you need a workaround like `[ "$(date +\%u)" = "1" ] && job` inside the script, or use a scheduler that supports AND semantics.
• cron-parser is timezone-aware; system cron is not. The calculator runs in UTC by default. The cron daemon on a Linux box runs in the system's timezone (usually whatever `/etc/timezone` says), and crontabs written for one server may fire at a different wall-clock hour on another. If your job needs to land at "9 AM London time", set the server TZ explicitly (`TZ=Europe/London` at the top of the crontab) — relying on the default is fragile.
• DST transitions skip or duplicate firings. On the spring-forward day, cron jobs scheduled inside the missing hour (typically 02:00–03:00 local) do not fire. On the fall-back day, jobs scheduled inside the duplicated hour fire twice. The calculator hides this because it works in UTC, but if you re-base into a DST-observing zone you will see the gap. Use UTC for any job whose correctness depends on running exactly once per scheduled minute.
• Months are 1-12, days are 1-31, weekdays are 0-6 (or 1-7). Unlike JavaScript Date, cron months are not zero-indexed: January is 1, December is 12. Day-of-week accepts 0 OR 7 for Sunday, which has bitten parsers that assumed 0-6. cron-parser supports both. Also note: cron does not validate impossible dates like Feb 30 — it simply never matches them, fires nothing, and gives no warning.

Frequently asked questions about Cron Next Run Calculator

Glossary

Cron expression

A 5-field string describing a recurring schedule: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-7, 0 and 7 both Sunday). Fields can use `*`, ranges (`1-5`), lists (`1,3,5`), steps (`*/15`), or names (MON, JAN).

POSIX cron

The standard cron format defined by IEEE Std 1003.1, used by Linux, BSD, and macOS. 5 fields, no seconds, no year, no L/W/# extensions. Most online cron tutorials describe POSIX cron.

Quartz cron

An extended cron format from the Java Quartz scheduler. 6 or 7 fields (adds seconds and optional year), supports L (last day), W (nearest weekday), # (nth weekday). Used by Spring Scheduler and ports to other languages.

Step value

The `/N` syntax for "every N units within the range". `*/15` in the minute field means every 15 minutes (:00, :15, :30, :45). `1-30/5` means 1, 6, 11, 16, 21, 26 — step within an explicit range.

OR semantics

POSIX cron quirk: when day-of-month and day-of-week are both restricted (not `*`), a firing happens when EITHER matches. `0 0 15 * 1` fires on the 15th of every month AND on every Monday — not just on the 15ths that are Mondays.

@daily / @hourly aliases

Convenience strings that expand to common expressions: `@hourly` = `0 * * * *`, `@daily` = `0 0 * * *`, `@weekly` = `0 0 * * 0`, `@monthly` = `0 0 1 * *`, `@yearly` = `0 0 1 1 *`. `@reboot` is a system-event hook, not a schedule.