CronLens

Cron next-run calculator with DST report

Pick a dialect, a time zone and a start date, and list the next runs. The report below the list shows what the schedule does around each daylight saving change, and which products document that behaviour and which do not.

    History and favourites (stored only in this browser)

      Nothing saved yet. Expressions you check are saved here, in your browser's local storage, never on a server.

      Runs locally. The expression is never uploaded. The share link keeps it after the # sign, which browsers never send to a server.

      How to use

      1. Choose the dialect and enter the expression. The calculator accepts every dialect on this site, so you can compare how the same job behaves in different systems.
      2. Type the IANA time zone of the schedule, for example America/New_York. A zone without daylight saving, such as Asia/Jakarta or UTC, never has a gap or an overlap.
      3. Enter a start date in that zone, for example 2026-03-07 12:00, to look at a particular period instead of the present. Runs start strictly after that moment.
      4. Read the list. Each run shows its local time, UTC offset and the equivalent UTC time, so a repeated local time is visible as two lines with different offsets.
      5. Open the daylight saving report under the tool. It lists the next four clock changes in the zone and the runs within six hours either side of each, as this dialect would produce them.

      Worked examples

      In 2026 New York moves its clocks forward on Sunday 8 March (02:00 becomes 03:00) and back on Sunday 1 November (02:00 becomes 01:00). The lists below use those dates.

      Fixed time inside the gap: 02:30 on Linux

      For a fixed-time job, cron(8) says a job skipped by a forward change runs immediately afterwards, so on 8 March the 02:30 job runs at 03:00. This is the manual's description of cronie; crontab(5), in the same package, says missing times never match, so the two pages disagree and this tool marks the behaviour as unclear.

      Linux / Vixie cron, time zone America/New_York, runs after 2026-03-07 12:00 UTC
      30 2 * * *

      1. Sun 2026-03-08 03:00:00 -04:00
      2. Mon 2026-03-09 02:30:00 -04:00
      3. Tue 2026-03-10 02:30:00 -04:00

      Fixed time inside the overlap: 01:30 on Linux

      cron(8) says a fixed-time job is not repeated after a backward change, so it runs once, at the first 01:30 (-04:00). crontab(5) says repeated hours run twice.

      Linux / Vixie cron, time zone America/New_York, runs after 2026-10-31 12:00 UTC
      30 1 * * *

      1. Sun 2026-11-01 01:30:00 -04:00
      2. Mon 2026-11-02 01:30:00 -05:00

      A frequent job: every 30 minutes

      */30 * * * * starts its minute field with a star, so cron(8) treats it as a job that is scheduled normally. During the repeated hour it keeps its rhythm in real time: the 01:00 and 01:30 runs happen once at -04:00 and once at -05:00.

      Linux / Vixie cron, time zone America/New_York, runs after 2026-11-01 04:00 UTC
      */30 * * * *

      1. Sun 2026-11-01 00:30:00 -04:00
      2. Sun 2026-11-01 01:00:00 -04:00
      3. Sun 2026-11-01 01:30:00 -04:00
      4. Sun 2026-11-01 01:00:00 -05:00
      5. Sun 2026-11-01 01:30:00 -05:00
      6. Sun 2026-11-01 02:00:00 -05:00

      Quartz in the overlap

      Observed with Quartz 2.3.2 on JDK 17: 0 30 1 * * ? fires once, at the second occurrence of 01:30 (-05:00), where Linux fires at the first.

      Quartz, time zone America/New_York, runs after 2026-10-31 12:00 UTC
      0 30 1 * * ?

      1. Sun 2026-11-01 01:30:00 -05:00
      2. Mon 2026-11-02 01:30:00 -05:00

      Summary of what each system does

      SchedulerSkipped hour (spring forward)Repeated hour (fall back)Where it comes from
      AWS EventBridge SchedulerSkipped that dayRuns once, at the first occurrenceDocumented
      GitHub ActionsAdvances to the next valid time (02:30 runs at 03:00)Not documented; the tool shows one run, at the first occurrenceGap documented, overlap unclear
      Kubernetes CronJobSkipped that dayRuns twiceObserved on robfig/cron v3.0.1; Kubernetes docs are silent
      QuartzSkipped that dayFires once, at the second occurrenceObserved on Quartz 2.3.2, JDK 17; docs say only "skip or repeat"
      Linux cron, fixed timeRuns just after the changeRuns oncecron(8); contradicted by crontab(5), so unclear
      Linux cron, minute or hour field starts with *SkippedRuns againcrontab(5) and cron(8); cron.c source

      Limits & gotchas

      • Only some rows are documented. The AWS Scheduler rules and GitHub's spring-forward rule are in the vendor's documentation. The Kubernetes and Quartz rows are what we saw when running the real libraries (robfig/cron v3.0.1 and Quartz 2.3.2), which can change in a later version. The Linux row combines two manual pages that disagree.
      • Gaps longer than an hour. cron(8) says its special handling applies to time changes of under three hours. Some zones have made changes of other sizes (for example half an hour at Lord Howe Island). The calculator uses the zone's rules from your browser's time zone data, but we have not checked every unusual zone against each scheduler.
      • Your browser's time zone data matters. The calculator uses the browser's Intl time zone database. A very old browser may not know a recent rule change that a server has.
      • It cannot see your server. A Linux machine might run in a different zone than you expect (for example UTC in a container) and Kubernetes without timeZone uses the controller's zone.
      • Scheduled instants only. Actual start times can lag: GitHub warns of delays under load, and AWS of several seconds.

      FAQ

      What is the difference between a gap and an overlap?

      A gap is the hour that is skipped when clocks move forward, for example 02:00 to 03:00 in New York on 8 March 2026: times such as 02:30 never exist that day. An overlap is the hour repeated when clocks move back, for example 01:00 to 02:00 on 1 November 2026: 01:30 happens twice. Schedulers decide differently what to do in each case.

      Does a job at 02:30 run on the day clocks spring forward?

      It depends on the scheduler. AWS EventBridge Scheduler skips it for that day (documented), GitHub Actions runs it at 03:00 (documented), Kubernetes and Quartz skip it (observed, not documented), and cronie's cron(8) manual says a fixed-time job runs immediately after the change. The tables on this page show each one.

      How do I avoid the problem completely?

      Run the job in UTC, which has no daylight saving, or schedule it at a time that is never inside the skipped or repeated hour of your zone, such as 04:15. If a job must run exactly once per calendar day, also make it idempotent so that a second run is harmless.

      Can I start the list from a date in the past or future?

      Yes. Type a start date and time like 2026-03-07 12:00 in the "Start from" box, which is read in the time zone you chose. Leave it empty to start from now. The daylight saving report under the list always looks at the next four changes after the start.

      Why does my result differ from another cron calculator?

      Because the dialects genuinely differ: day-of-week numbering, the OR rule for the two day fields, the ? character, seconds and year fields, and the treatment of clock changes. Select the dialect that your scheduler uses, and read the notes where this tool says a behaviour is observed or unclear rather than documented.

      Sources

      Every document above was opened and read on 2026-10-01. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.