Cron Jobs and Daylight Saving Time: Skipped and Missed Runs

Published 12 Oct 2026 · 8 min read

Twice a year, the local clock jumps. In the United States it skips 02:00 to 03:00 in March and repeats 01:00 to 02:00 in November. A cron job set for a time inside that window has no obvious right answer, and different schedulers give different ones. This post shows what Cron Master does, which runs on the croner library, version 9.1.0, under Node 22. I ran every schedule below there. I did not run Vixie cron, cronie, systemd timers, Kubernetes CronJobs or any cloud scheduler, so treat what follows as one scheduler's verified behaviour and a list of things to test on yours.

The two transition days, in US Eastern time

In 2027 the clocks in America/New_York go forward on 14 March (02:00 EST becomes 03:00 EDT). In 2026 they go back on 1 November (02:00 EDT becomes 01:00 EST). The table lists what croner produced for each schedule on those days. "Late" and "gap" are measured against the schedule you wrote.

1. A job inside the skipped hour runs an hour late

On 14 March 2027 the wall clock in New York goes from 01:59 EST straight to 03:00 EDT, so 02:30 never happens. A daily 30 2 * * * does not vanish for the day; croner moves it to the next valid time:

30 2 * * *   America/New_York   from 2027-03-12
Sat 13 Mar 02:30 EST   (07:30 UTC)
Sun 14 Mar 03:30 EDT   (07:30 UTC)   <- one hour late on the clock, the same UTC instant
Mon 15 Mar 02:30 EDT   (06:30 UTC)

Notice that Saturday and Sunday are both 07:30 UTC. The job did not move in absolute time; the clock moved under it. That is worth remembering when something downstream expects 24 hours between runs and sees 24 here and 23 the next day.

2. The weekly Sunday 2 AM job is the one that hits it every year

US daylight saving always starts on a Sunday at 02:00. A 30 2 * * 0 maintenance job, which many teams pick because Sunday early morning is quiet, therefore lands in the missing hour every spring:

30 2 * * 0   America/New_York   from 2027-03-07
Sun 14 Mar 03:30 EDT   (07:30 UTC)
Sun 21 Mar 02:30 EDT   (06:30 UTC)
Sun 28 Mar 02:30 EDT   (06:30 UTC)

It still runs, an hour late. If that job takes the system offline for a window you announced to users, the window now starts at a different clock time once a year.

3. A job inside the repeated hour runs once

On 1 November 2026 the clock reads 01:30 twice: first in EDT, then, an hour later, in EST. A daily 30 1 * * * fires only on the first of them:

30 1 * * *   America/New_York   from 2026-10-30
Sat 31 Oct 01:30 EDT   (05:30 UTC)
Sun  1 Nov 01:30 EDT   (05:30 UTC)   <- the second 01:30 (EST, 06:30 UTC) does not fire
Mon  2 Nov 01:30 EST   (06:30 UTC)

So under croner you do not get a duplicate run. A scheduler that fires on every matching wall-clock minute would run it twice, which is exactly the case to test in yours if the job is not safe to repeat (sending a report, charging a card, rotating a log).

4. Hourly and half-hourly jobs open a gap in November

Because the repeated hour is not run a second time, a job that is supposed to be frequent shows a longer silence than you would expect once a year:

0 * * * *   America/New_York   from 2026-11-01 00:00 EDT
00:00 EDT   (04:00 UTC)
01:00 EDT   (05:00 UTC)
02:00 EST   (07:00 UTC)   <- 06:00 UTC (01:00 EST) never fires: two hours since the last run

A monitor that alerts when a heartbeat is more than 75 minutes old will page someone at 01:15 EST on 1 November for a job that is behaving as designed. In spring there is no gap in real time: 01:00 EST is followed by 03:00 EDT, which is one hour later, so an hourly job just skips a label on the clock.

5. A job in UTC is stable, but its local meaning is not

The other common setup is a server in UTC, which has no daylight saving at all. Nothing is skipped or repeated, but a schedule that was "10:00 in the office" in summer is "09:00 in the office" in winter:

0 14 * * *   UTC
2026-10-30 14:00 UTC = 10:00 EDT
2026-11-03 14:00 UTC =  9:00 EST

That is the trade-off. UTC gives you predictable intervals and no ambiguous hours; a local-time schedule gives you the clock time people expect and a transition-day surprise. Neither is wrong, but pick on purpose, and note which one your host uses: a server's system time zone is often not the one you assumed. (This one is plain offset arithmetic, so it has no Cron Master link.)

What to do about it

1. Prefer UTC for anything that must run at regular intervals or exactly once a day. Backups, billing runs and data syncs usually do not care what the wall clock says.
2. If the job must follow local time, keep it out of 01:00 to 03:00. Moving 30 2 * * 0 to 30 4 * * 0 removes both transition problems for US zones. Other regions change at other times, so check yours.
3. Make the job safe to run late or twice. Use an idempotency key, a lock file or a "last successful run" check, so a late run in March or a duplicate in November is harmless.
4. Test your actual scheduler on both transition days. Point it at a throwaway job in a test environment with a faked clock, or at least read how its documentation describes ambiguous and non-existent local times. Do not carry the table above over to a different scheduler.
5. Tune heartbeat alerts. If a local-time schedule feeds a "no run in N minutes" alert, allow for the two-hour November gap.

How the links on this page were produced

Each "Open this schedule in Cron Master" link carries the expression, a time zone and a start date in the URL (?expr=, ?tz= and ?from=), so the Next 10 Executions list starts from that date instead of from today. The simulation runs in your browser and nothing is sent anywhere. The start date is read as UTC, which is why the examples start at midday UTC two days before the transition. The list prints each time with its zone abbreviation (EST or EDT), which is how you can tell the two 01:xx hours apart. The time zones available are the ones in the Timezone drop-down.

Frequently asked questions

What happens to a cron job scheduled at 2:30 AM when the clocks spring forward?

In croner 9.1.0, the library behind Cron Master, 30 2 * * * in America/New_York runs at 03:30 EDT on the spring-forward day (2027-03-14) instead of being skipped, because 02:30 does not exist that day. The next day it is back to 02:30. Other schedulers may behave differently, so check the documentation of the one you use.

Does a cron job run twice when the clocks fall back?

In croner 9.1.0 a fixed-time job such as 30 1 * * * in America/New_York runs once on the fall-back day (2026-11-01), at the first 01:30 (EDT). The second 01:30 (EST) does not fire. Hourly and half-hourly jobs also skip the repeated hour, which leaves a longer real-time gap between two runs. Other schedulers may run the job twice.

How do I avoid daylight saving problems with cron?

Run the job in UTC, or move it outside the 01:00 to 03:00 local window, and make the job idempotent so a late or repeated run does no harm. If the job has to follow local wall-clock time, use a scheduler that takes an explicit time zone and test it against both transition days.

Related: the Cron Expression Cookbook covers the schedules themselves, including the day-of-month and day-of-week OR gotcha, and the complete cron guide covers syntax and debugging.

← Back to Blog · See also: Cron Expression Cookbook →