Cron Parser Next Runs

The top causes, in order: the server’s timezone is not yours (cron uses the system clock, check with date on the server), DST shifted the wall-clock time, the schedule uses day-of-month AND day-of-week (most crons run when either matches, not both), and a missing minute field turning your 5-field expression into nonsense. Paste your expression into this parser and compare the next-run times it shows, in both UTC and your local zone, against what you expected.

5 space-separated fields: minute (0-59) hour (0-23) day-of-month (1-31) month (1-12 or JAN-DEC) day-of-week (0-6, where 0=Sun, or SUN-SAT). Each field accepts: literal value (5), range (1-5), list (1,3,5), step (*/10), wildcard (*).

@yearly / @annually = 0 0 1 1 *. @monthly = 0 0 1 * *. @weekly = 0 0 * * 0. @daily / @midnight = 0 0 * * *. @hourly = 0 * * * *. Match Vixie cron and most cron flavours.

Not supported. @reboot only fires at system boot – meaningless for time-based “next runs”. L (last day), W (nearest weekday), # (nth weekday) are Quartz/cron-utils extensions not in standard Vixie cron. For schedules using these, use a Quartz-aware tool.

Calculation runs in your browser’s local timezone (matching where cron jobs typically run). Display lets you preview the same instants in a different zone. The ISO 8601 column always shows UTC – the unambiguous “what moment” representation.

It only happens in leap years. For a cron like 0 0 29 2 * (midnight Feb 29), runs only appear in leap years 2024, 2028, etc. The calculator correctly skips non-leap-year Feb 29 attempts.

RFC 5545 .ics file with one VEVENT per run. Imports into Google Calendar, Apple Calendar, Outlook, etc. Each event is 0-duration (point in time). UID format cron-{expr}-{index}@alltoolsverse.com.

The gap from the previous run to the current run, shown next to runs #2+. Useful for verifying your cron’s actual cadence – e.g., 0 9 * * 1-5 gives 24h intervals Mon-Thu but 72h interval Fri→Mon.

The calculation uses JavaScript’s Date arithmetic, which respects browser local DST. On the night when clocks spring forward, jobs at the skipped hour (typically 2am-3am) won’t fire – the calculator correctly omits them. On the night clocks fall back, jobs at the repeated hour may appear twice depending on how Date handles it (browser-dependent). For high-precision DST behavior, run your own cron infrastructure with explicit TZ config.

No. Pure browser-side parsing and date calculation.