Skip to content
AZ Tools

Cron Next Runs

Type a 5-field cron expression and see the next N times it will fire — local time, including weekday + day-of-month dual semantics.

Upcoming runs
  • #110/19/2026, 9:00:00 AM
  • #210/20/2026, 9:00:00 AM
  • #310/21/2026, 9:00:00 AM
  • #410/22/2026, 9:00:00 AM
  • #510/23/2026, 9:00:00 AM
  • #610/26/2026, 9:00:00 AM
  • #710/27/2026, 9:00:00 AM
  • #810/28/2026, 9:00:00 AM

Times are in your local timezone — same one your browser is set to.

How to use

  1. Type a cron expression. The default 0 9 * * 1-5 means 9 AM on weekdays.
  2. Optionally set a different start time — useful for back-calculating from a past anchor or projecting from a future date.
  3. Pick how many upcoming runs to list (up to 50).

About this tool

Show

Parses standard 5-field cron (minute hour day month weekday) with ranges (1-5), lists (1,3,5), steps (*/15), and month / weekday aliases (mon, jan). The result list shows the next runs starting from now (or a fixed timestamp), in your local timezone. When both day-of-month and day-of-week are restricted, either match counts as a hit — matching the original Vixie cron semantics.

That last rule is the one worth reading twice, because it is a union and not an intersection. 0 0 13 * 5 fires on the 13th of every month and on every Friday, which comes to about 62 days a year rather than the 1.7 that are actually a Friday the 13th. The list of upcoming runs is the fastest way to catch this: if a schedule you meant to be rare shows a run tomorrow, the two day fields are fighting. When only one of the two is restricted the rule does not apply, and the schedule reads exactly as you would expect.

Step values are computed over the field's own range rather than as a repeating interval from the last run. */15 in the minute field means minutes 0, 15, 30 and 45, not "every fifteen minutes from whenever the job last ran", and 0 */5 * * * restarts its count at midnight, so the gap between the 20:00 run and the next one is four hours rather than five. Ranges combined with steps, as in 10-40/10, step within the range only.

Times are shown in your browser's timezone, which is a convenience for reading and a trap for deploying. A cron daemon uses the local time of its own host, and most hosted schedulers run in UTC no matter where you are. Around a daylight saving transition the two diverge visibly: a daily job in the skipped hour has no run that day, and one in the repeated hour has two.

Frequently asked questions

Is 1 * * * * once a day or once an hour?

Once an hour, at minute 1 of every hour. The first field is the minute — a literal value means "only when the clock reaches this value", and the other fields default to * (any). To run once a day at 1 AM, you'd write 0 1 * * *.

What's the deal with day-of-month vs weekday?

When both fields are something other than *, cron treats them as OR: the job runs if either condition matches. 0 0 1 * 1 fires on the 1st of every month and on every Monday. If you want AND, you have to enforce it inside the job itself.

Does this support 6-field (with seconds) or quartz cron?

Not yet — this is plain Unix cron, 5 fields starting from the minute. Quartz introduces a seconds field and additional features like L, W, and #.

Which clock does a cron schedule follow when the time zone shifts?

Traditionally the machine's local time, which makes daylight saving awkward twice a year: a job scheduled inside the hour that is skipped in spring may not run at all, and one inside the hour repeated in autumn may run twice. Anything whose correctness depends on running exactly once should be scheduled in UTC, or made safe to run twice.

The schedule looks right but the job did not run. What is usually wrong?

Rarely the expression. Far more often it is the environment: cron runs with a minimal PATH and none of your shell's setup, so a command that works in a terminal fails to be found. After that come a missing final newline in the crontab, output going nowhere because nothing redirects it, and the previous run still holding a lock. Log both streams to a file before debugging the schedule itself.

Guides on this topic

Related tools