n8n Schedule Trigger runs twice when the clocks go back: check your 2 a.m. workflows before Sunday 1 November

Check this today

1. Your version. In n8n, open Help → About n8n. Or, for Docker, run docker exec <container> n8n --version.

   • 2.5.0 to 2.44.x, which includes today's stable 2.44.7: affected. The one exception in n8n's 2.44.7 source is N8N_SCHEDULER_ENABLED=true together with the workflow publication service (on by default); we tested that only at engine level, not as a running server (below). We ran 2.44.7; n8n's team says the double run has affected n8n since 2.5.0, which matches its published dependencies (below). n8n says it will not fix the old in-memory scheduler these releases use.
   • 2.45.x (beta): its new scheduler is on by default. n8n says it runs these jobs once and that 2.45 will be the next stable release; it gave one run in our test, which was not a full server run. If you set N8N_SCHEDULER_ENABLED=false, it runs twice like 2.44.7.
   • 1.x and 2.0 to 2.4: a daily workflow ran once in our tests of 1.123.88 and 2.4.8. Hourly and every-30-minute workflows lost the repeated hour instead (below).

2. The time zone each workflow uses. Open the workflow, then ⋯ → Settings → Timezone. A zone you picked there wins. Default - … means the instance's zone, which comes from GENERIC_TIMEZONE. To see it for Docker:

   docker exec <container> printenv GENERIC_TIMEZONE

   If that prints nothing, the variable is not set and n8n uses America/New_York. Your server's own clock and TZ don't change this.

3. Workflows with a trigger at 2 a.m. in a US or Canadian zone (or with no zone set): a Schedule Trigger with Trigger at Hour set to 2am, or a Custom (Cron) expression whose hour field includes 2 but not 1: 2, but also */2 (every 2 hours), a list such as 2,14 or a range such as 2-4. Because 1 November is a Sunday and the 1st of the month, include Weeks triggers on Sunday and Months triggers on day 1 at 2am. With many workflows, list every trigger at once (below).

4. Change each one you find, before Sunday. For daily schedules, each of these ran once on 1 November in our 2.44.7 tests:

   • Move it out of 02:00 to 02:59 local, for example to 03:30. 01:30 also ran once, so only the 02:xx hour needs moving.
   • Or set the workflow's Timezone to UTC and enter the time in UTC: 02:30 New York from 1 November is 07:30 UTC. A UTC schedule stays put in UTC, so its local time moves an hour whenever the clocks change: 07:30 UTC is 03:30 in New York until Sunday and again from 14 March 2027.
   • For a Custom (Cron) every 2 hours (*/2 in the hour field), moving the time doesn't fit. Set the workflow's Timezone to UTC, or replace the expression with the Schedule Trigger's Hours mode set to 2 hours between triggers, which ran without an extra run on a running 2.44.7 server in our test.

   Then publish the workflow. On n8n 2.x an edited workflow is a draft until you publish it, and the published version is the one that runs, so saving alone may leave the old schedule in place. Open the published version and check that it shows the new time or zone.

What we measured

We used three methods. Rows for 2.44.7, 2.4.8 and 1.123.88 by default, and 2.45.4 with N8N_SCHEDULER_ENABLED=false, ran n8n's own installed Schedule Trigger node and in-memory scheduler, unchanged, with a simulated clock from 31 October 12:00 to 2 November 12:00 UTC and the week before as a control. Rows for 2.45.4 by default and 2.44.7 with N8N_SCHEDULER_ENABLED=true ran only the new scheduler's own planner and run loop, with an in-memory job store, from 1 November 01:00 to 13:00 UTC and the same hours on 25 October as a control; the Schedule Trigger node and n8n's server were not part of that test. Third, we ran the official 2.44.7 Docker image as a server (n8n start, SQLite, no zone set) with 16 published workflows, on a clock running 120 times faster from 31 October 05:00 to 1 November 08:45 UTC, and counted the executions it saved. Every daily, weekly and monthly result it covered, in New York, Chicago, UTC and with no zone set, matched the other methods, except every 2 days, which depends on the day it last ran (below). "Twice" means two runs on 1 November, one hour apart.

The double run comes with the cron library version n8n uses for its in-memory scheduler: 2.4.8 and 1.123.88 use cron 3.1.7 and ran once; 2.44.7 and 2.45.4 (with the new scheduler off) use 4.4.0 and ran twice. n8n moved to 4.4.0 in 2.5.0, by its published dependencies; we did not run 2.5.0 itself. n8n's team names the same cause: the cron library used by the in-memory scheduler, affecting n8n since 2.5.0. This matches the Berlin report, where the trigger in the hour after the repeated hour ran twice and the triggers inside the repeated hour did not.

Weekly and monthly schedules

1 November is a Sunday and the first of the month, so weekly and monthly jobs meet the same hour. On 2.44.7, in New York:

• Weeks, Sunday at 02:30: twice, at 01:30 and 02:30. Sunday at 03:30: once.
• Months, day 1 at 02:30: twice, at 01:30 and 02:30.
• Custom (Cron) 0 30 2 * * 0 (Sundays) and 0 30 2 1 * * (the 1st): twice each.
• Days, every 2 days at 02:30: in a test that started with no earlier runs, once, but at 01:30, an hour early. On a running server where it had run on Saturday, it did not run on Sunday at all, as it should. Which of the two you get depends on the day it last ran.

We did not run the two changes above on these weekly, monthly and every-2-days schedules. They ran once for daily schedules, and we expect the same here, but check after you change them.

The new scheduler on 2.44.x

n8n 2.45 turns on a new scheduler by default, and 2.44.x already contains it behind N8N_SCHEDULER_ENABLED=true. In n8n's 2.44.7 source, that setting sends Schedule Trigger and the old Cron node to the new scheduler, whose run-time calculation gave one run in our test. We did not run it as a full server, so treat it as an option to test, not a tested fix. What the source says it needs and changes:

• It works only with n8n's workflow publication service on, which is the default (N8N_USE_WORKFLOW_PUBLICATION_SERVICE). It runs on main instances, not on queue-mode workers.
• The source sets up the new scheduler's jobs when a workflow is activated. We did not check whether a restart moves workflows that are already active, so after the change unpublish and publish again the workflows that matter, and confirm when they next run.
• On 2.44.x, every-N-seconds and every-N-minutes triggers keep their clock-aligned timing. On 2.45 they change to intervals counted from activation (N8N_SCHEDULER_TRIGGER_NODE_MODE).
• n8n 2.45 marks N8N_SCHEDULER_ENABLED as deprecated, to be removed in a later version.

The workflow-level changes above need none of this.

Older releases: the repeated hour goes missing

On 2.4.8 and 1.123.88 a daily 02:xx workflow ran once, on time. But an hourly workflow ran 47 times in the 48 hours around the change, with no run at 06:00 UTC (01:00 EST, the second 01:00), and an every-30-minutes workflow ran 94 times instead of 96. If those runs matter, for example counting or billing by the hour, plan for one missing hour on Sunday morning. On 2.44.7 both ran every time.

List every schedule at once

On a self-hosted instance, export every workflow to a file and list the Schedule Trigger and Cron nodes with jq.

Treat the export as private. n8n's credential store is not in it, but everything in your workflows is: values typed into nodes, including any API keys or tokens pasted there instead of saved as credentials, and pinned test data. The listing below also prints node settings to your terminal. Keep the file to yourself and delete both copies when you're done (commands below).

For Docker:

docker exec <container> n8n export:workflow --all --output=/tmp/workflows.json
docker cp <container>:/tmp/workflows.json .

Without Docker, run n8n export:workflow --all --output=workflows.json as the user that runs n8n. Then:

jq -r '.[] | . as $w | .nodes[]
  | select(.type == "n8n-nodes-base.scheduleTrigger" or .type == "n8n-nodes-base.cron")
  | [$w.name, (if $w.active then "active" else "inactive" end), ($w.settings.timezone // "default"), (.parameters | tojson)]
  | @tsv' workflows.json

On a test instance of 2.44.7 with nine workflows, it printed this (columns are separated by tabs):

Daily report 02:30, no timezone	active	default	{"rule":{"interval":[{"triggerAtHour":2,"triggerAtMinute":30}]}}
Invoices on the 1st 02:00 Chicago	inactive	America/Chicago	{"rule":{"interval":[{"field":"months","triggerAtHour":2}]}}
Sunday backup 02:15 UTC	active	UTC	{"rule":{"interval":[{"field":"weeks","triggerAtHour":2,"triggerAtMinute":15}]}}
Cron 0 30 2 * * * Los Angeles	inactive	America/Los_Angeles	{"rule":{"interval":[{"field":"cronExpression","expression":"0 30 2 * * *"}]}}
Hourly sync	inactive	default	{"rule":{"interval":[{"field":"hours"}]}}
Midnight daily	inactive	default	{"rule":{"interval":[{}]}}
Legacy Cron node 02:00	inactive	default	{"triggerTimes":{"item":[{"hour":2}]}}
Two rules 01:00 and 02:45	active	America/New_York	{"rule":{"interval":[{"triggerAtHour":1},{"triggerAtHour":2,"triggerAtMinute":45}]}}

Read it one column at a time:

• Second column: active means the workflow is published or active; those are the ones to check. A trigger node you disabled is listed too.
• Third column: the workflow's zone. default means the instance's zone: GENERIC_TIMEZONE, or America/New_York if that is not set. UTC is not affected.
• Last column: look for "triggerAtHour":2. A rule with no "field" is Days. In an "expression", the hour is the third of six fields, or the second of five; check it if it includes 2 but not 1, such as 2, */2, 2,14 or 2-4. In the old Cron node it is "hour":2.

Here, "Daily report 02:30, no timezone" and the second rule of "Two rules 01:00 and 02:45" need changing. "Sunday backup 02:15 UTC" runs in UTC, and the rest are not active.

The export lists each workflow as last saved. If you have edited a workflow since you last published it, check the published version in the editor too.

When you're done, delete both copies:

docker exec <container> rm /tmp/workflows.json
rm workflows.json

Already ran twice?

If you are reading this after 1 November: two executions of the same workflow one hour apart, the first at 01:xx and the second at 02:xx local time, are consistent with this issue. Check the version, the scheduler setting, the workflow's zone and its published trigger time against the steps above. Look in Executions for that workflow on 1 November, check what the extra run did (emails, invoices, posts, database writes), then apply one of the changes above, or move to 2.45 once it is the stable release, before the next change. Europe and the US change again in March, but that change skips an hour instead of repeating one.

Where the fix stands

On 26 October n8n closed #42070 as fixed in 2.45.0. From 2.45.0 the Schedule Trigger runs on the new scheduler by default, which n8n says does not use cron and runs these jobs once. 2.45 was still in beta that day; n8n says it will be the next stable release. The old in-memory scheduler, which 2.44.x and earlier use by default, is deprecated and will be removed, so n8n will not fix it. Until you upgrade, n8n's own advice is to move the jobs out of the affected hour, as above. A fix in the cron library itself (kelektiv/node-cron#1092) was open and not merged. We'll update this page when 2.45 becomes the stable release.

What we tested

• n8n 2.44.7, 2.45.4, 2.4.8 and 1.123.88, installed from npm on 26 October 2026 into Node 24.22.1 (tzdata 2026e), one clean container per release with no network.
• For 2.44.7, 2.4.8 and 1.123.88, and 2.45.4 with the new scheduler off: n8n's installed Schedule Trigger node and in-memory scheduler, unchanged, run under a simulated clock from 31 October 12:00 UTC to 2 November 12:00 UTC, with the week before as a control. The time zone came from n8n's own workflow and config code, which is how we know an unset zone means New York.
• For 2.45.4 by default, and 2.44.7 with N8N_SCHEDULER_ENABLED=true: the new scheduler's own planner, run loop and run-time calculation with an in-memory job store, 1 November 01:00 to 13:00 UTC. Not tested: the Schedule Trigger node, n8n's database store, workflow activation, leader election and a real execution.
• For 2.44.7 also: the official n8nio/n8n:2.44.7 image run as a server (n8n start, SQLite, no GENERIC_TIMEZONE or TZ), 16 workflows imported, published and restarted on a clock running 120 times faster from 31 October 05:00 to 1 November 08:45 UTC; executions counted from n8n's own database. The faster clock covered n8n's process, not the operating system, so it is not a real clock change.
• Schedules: Days with one day between runs, Custom (Cron), Hours and Minutes. On 2.44.7 only, in New York: Weeks (Sunday at 02:30 and 03:30), Months (day 1 at 02:30), Days every 2 days (02:30) and the two Custom expressions above.
• n8n's import, publish and export commands on the official n8nio/n8n:2.44.7 Docker image with no network, on nine test workflows, three of them published; the jq listing on our own machine, on that export. We did not run the docker cp or rm steps.
• We did not test zones other than New York, Chicago, Los Angeles and UTC, n8n Cloud, or a running n8n server through a real clock change.
• What we saw is two runs from releases on cron 4.4.0. We did not trace the cause in the library's code ourselves; n8n's team names the cron library as the cause.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something on this page is wrong or has changed, email hello@cybernative.ai. We correct the page and list each correction here with its date.