Cron tools › Explain / Test

Next run calculator

next · previous · between two dates · DST-aware

When will this cron job run? List the next or previous runs of any expression in the time zone the scheduler uses, or every run between two dates, with the busiest and quietest gaps and each daylight-saving problem called out.

Cron expression

Dialect Time zone

Show How many

Runs

Try one

How to calculate cron run times

Type or paste the expression. Pasting an AWS cron(…), a six-field Quartz or Spring expression or a Jenkins H spec switches the dialect to match; check it in Dialect.
Pick the Time zone the scheduler evaluates the schedule in — the server's zone for Linux cron, UTC for GitHub Actions and EventBridge rules, .spec.timeZone for a Kubernetes CronJob.
Choose Next runs, Previous runs or Every run between two dates, and how many runs to list (up to 1,000). The two dates are read as wall-clock times in the chosen zone.
Read the summary: runs per day and per week, and the shortest and longest gap between the listed runs. An uneven gap usually means a step such as */7 that restarts every hour.
Check any run flagged DST gap or repeated hour and the explanation above the list, then use Download CSV or Copy as list to take the times with you.

What daylight-saving time does to a schedule

Twice a year local time skips or repeats an hour. A schedule evaluated in UTC never sees this, but one evaluated in a local zone does, and schedulers handle it differently:

Scheduler	Run time that is skipped (spring forward)	Run time that happens twice (fall back)
Vixie cron / cronie	A fixed-time job runs immediately after the jump. Jobs with `*` in the minute or hour field are scheduled normally, so those runs do not happen.	A fixed-time job runs once ("running the same job twice is avoided").
GitHub Actions with `timezone:`	A 2:30 AM run in the skipped hour advances to 3:00 AM.	Not documented.
EventBridge Scheduler	The skipped time is skipped.	The repeated hour runs once.
UTC-only: EventBridge rules, Vercel, Cloudflare Workers, GitHub Actions without `timezone:`	Nothing is skipped or repeated in UTC, but the local time of each run shifts by an hour when your clocks change.

cronie's special handling applies to clock changes of less than three hours and only to jobs at a specific time or with a granularity above one hour; Debian's cron(8) says only jobs without * in the hour or minute field (and not @hourly) are affected. The run list follows the Vixie/cronie rule. To see a whole month of clock-change days at once, open the schedule visualizer.

Reading the gaps

The shortest and longest gap are measured between consecutive runs in the list, so they expose schedules that are not as even as they look. */7 * * * * runs at :00, :07 … :56 and then :00 again, so the shortest gap is 4 minutes, not 7. 0 9 * * 1-5 has a 1-day gap on weekdays and a 3-day gap over the weekend. Runs per day and per week are counted over the next 52 weeks, so a schedule restricted to certain months or days shows its true average.

FAQ

Why would I want the previous runs?

To check when a job should last have run — for example when a report is missing and you need to know whether the 02:30 run was due before or after a deploy. The previous-runs list is newest first and uses the same time zone and DST rules.

How are the From and To dates interpreted?

As wall-clock times in the selected time zone, both ends included. A time that falls in a daylight-saving gap is read as the moment just after the clocks jump. If a window holds more than 1,000 runs, the first 1,000 are listed and the page says so.

Does the list account for scheduler delays and missed runs?

No. It shows when the schedule is due. Some platforms start late: GitHub Actions warns of delays at times of high load, "especially at the start of every hour", and may drop queued runs; a Kubernetes CronJob that has missed more than 100 schedules creates no Job at all.

Why does a run show as "in 3d 4h" and not in minutes?

The last column is a rounded distance from now, to scan the list quickly. The exact wall-clock time and the matching UTC time are in the columns beside it, and the CSV export has the full UTC timestamp of every run.