Why your 8am automation runs at 7am after the clocks change

September 2, 202616 min readUpdated September 13, 2026

The reminders went out at seven in the morning. Nobody had touched the workflow. On Friday the same job had gone out at eight, and over the weekend the clocks moved without it.

Automation running at the wrong time after daylight saving is a fault with a date on it. It arrives twice a year, on days anyone can look up in advance. Owners still find out from the outside: a customer replying at seven, a daily report that covered the wrong day.

Four things decide what happens to your 8am job that weekend: which clock it actually follows, what the vendor documents about the transition, whether a missed run is caught up or thrown away, and which of the fixes hold. I read these vendor pages in August 2026, and they move, so check the vendor's page rather than this one.

Which clock does your 8am actually run on?

Almost never the one you think you set. On Zapier a schedule follows the account timezone. On Make it follows the organisation time zone, which only an owner or admin may edit. On n8n it follows the workflow timezone when one is set, and the server's setting otherwise. On Power Automate it follows a field on the trigger, and only when you also give a start time.

Four platforms, four different answers, none of them the clock on your wall.

Zapier says so under a heading called Limitations, on the page you open to build the schedule. "Schedule triggers use the timezone set in your Zapier account, not the timezone set in your Zap. If you change your account timezone, turn the Zap off and back on for the change to take effect."

Two traps in one sentence. The setting sits a level away from the Zap you were looking at, and changing it does nothing until somebody toggles that Zap. The starting value matters too: "By default, your account is set to the UTC time zone." UTC is the world's reference clock, the one London keeps in winter and runs an hour ahead of in summer, so a brand-new Zapier account is on a clock that is nobody's local time for half the year.

Make splits the clock in two, on a page away from the scheduler. "The organization time zone defines the time used when executing scenarios and modules." The user time zone "only impacts how Make displays information", so what you see and what runs are two settings.

n8n has a default that surprises people. Its Schedule Trigger page says the node uses the workflow timezone if set, and "the n8n instance timezone" otherwise. Self-hosted, that default is America/New York, so an n8n nobody configured runs your morning job on New York time.

Microsoft attaches the clock to the trigger, and the Time Zone field "applies only when you specify a start time". A foot-gun sits beside it: add a "Z" to that start time and "Azure Logic Apps ignores the time zone value".

What does the wrong hour look like from the customer's side?

Like a job that moved and told nobody. It takes three shapes, and no platform flags any of them.

The first is the message sent an hour early or an hour late. A schedule set to 7:30am in the account's timezone keeps firing at 7:30 in whatever the platform counts as the account's timezone, and after the clocks go forward that is 8:30 on the wall. The customary fix, offered on every vendor forum, is to adjust the trigger time by hand, and then adjust it back again in the autumn.

The second is the report covering the wrong day. A scenario that ran at 11:15 local time now runs at 10:15, and if it pulls "yesterday's" figures by the clock, it pulls the wrong day's detail. Nothing errors; the numbers are simply for the day before the one on the heading.

The third fails in advance. Make's community, March 2026: a customer creating calendar events during standard time for dates in daylight time found that "once DST happens, everything on the calendar is off by an hour". A Make employee traced it to a hardcoded time zone in a date function: the system reads the offset as it stands when the scenario runs, "rather than the offset that will exist on the target date".

That customer's reply the next day is the whole problem in one line. "I have made the suggested changes, but unfortunately will not really know if it works until DST changes again."

Every one of those runs finished green. A tick says a workflow ran, not that it did the right thing, and why automations fail silently covers how to make silence readable.

If you would rather have somebody go through everything in your business that runs on a clock, and say which of those jobs care about the hour, that is the process audit. $299, three business days, a written map of your processes with what each one is worth. You keep it whether or not you hire us.

Four platforms, side by side

Very little is documented, and the emptiness is the finding. Eleven of the twenty-four cells below read "not documented". One vendor of the four publishes what happens to a schedule at the transition, and that vendor asks you to adjust the schedule yourself. Read in August 2026, and these pages change.

	Zapier	Make	n8n	Power Automate (Logic Apps engine)
Which setting governs the schedule	Account timezone, "not the timezone set in your Zap". Defaults to UTC. A 2024 Zapier staff post says the opposite; see below.	Organisation time zone. The user time zone only changes what you see. Not named on the scheduling page.	Workflow timezone if set, otherwise the instance timezone. Self-hosted default `America/New York`; Cloud detects at signup, "falling back to GMT".	The Time Zone field on the Recurrence trigger, and only with a start time.
Does a change take effect at once	No. "Turn the Zap off and back on for the change to take effect."	Not documented.	Not documented for the timezone. A changed schedule "begins from the time when you publish the workflow".	Not documented. The docs say to "manually adjust the recurrence" instead.
Is the clock change documented	No. Zero matches for "daylight" or "DST" on either scheduling page.	No in the help centre. Older forum posts from staff cover only how logs display.	No on the Schedule Trigger pages. One sentence on the durable scheduler page.	Yes, on the Azure Logic Apps recurrence pages. No on Power Automate's own scheduling page.
A run in the skipped hour	Not documented.	Not documented.	Not documented. Nearest: the older scheduler "could be off by one period".	A hazard, not a promise: such a start time may "become invalid or ambiguous".
A run in the repeated hour	Not documented.	Not documented.	Not documented.	An overlap risk: two jobs in "the same ambiguous interval" may "overlap".
Are missed runs replayed	Not documented. Nearest is a tolerance: no guarantee of "the precise minute you set".	Not documented.	No by default. Catch-up exists from version 2.36, durable scheduler only.	Recurrence: no. Sliding Window (a Logic Apps trigger, not documented for cloud flows): it "goes back and processes the missed recurrences".

Read across a row rather than down a column. The first row says the setting you need lives somewhere other than the screen you are on, in three cases of four. The last three rows are mostly blank, and blank means nobody has told you.

Which vendors document automation running at the wrong time after daylight saving?

One of the four. As of August 2026 the words "daylight" and "DST" return zero matches on Zapier's schedule page and on its page about incorrect dates. Zero matches on n8n's Schedule Trigger page and its common issues page. Nothing in the Make help centre pages I read. Those are searches over page text on a stated date, and I ran them so that this section could say something narrower and more useful than "the vendors handle DST badly": three of the four say nothing about it at all, on the pages an owner would actually open.

The n8n case is the sharpest. Its common issues page carries a heading called "Scheduled workflows run at the wrong time", and the whole diagnosis under it is configuration: "you need to adjust the time zone n8n uses". A page about schedules running at the wrong time, silent about the two days a year when they most reliably do. If you went looking for this answer where any reasonable person would look for it, you found a paragraph about setting a time zone and nothing at all about the morning the time zone moves underneath you.

n8n does say it once, in an unlikely place. Its durable scheduler page claims the newer scheduler handles "leap years, the 53rd week of a year, and daylight-saving transitions, where the in-memory scheduler could be off by one period". You would have to know that sentence exists in order to find it.

Make says nothing about it in the help centre at all. Its forum has older staff answers about how the logs display after a change, and nothing current on whether the schedule itself moves. On the public record, that question is unresolved.

What does the one vendor that documents it actually say?

Select a time zone and the platform moves the underlying time so your local time stays put. Miss that step and the run drifts by an hour twice a year. Microsoft publishes this on the Azure Logic Apps recurrence pages, the engine Power Automate cloud flows run on. Power Automate's own scheduling page does not mention daylight saving at all.

The instruction is plain. Specify a start time and "make sure that you select a time zone". Then "the UTC time for your logic app also shifts to counter the seasonal time change". Skip it, and "daylight saving time (DST) events might affect when triggers run".

Then a line that surprises people about a managed service. "To make sure that the recurrence time doesn't shift when DST takes effect, manually adjust the recurrence."

One hour is singled out. "Triggers that start between 2:00 AM - 3:00 AM might have problems because DST changes happen at 2:00 AM". The start time may "become invalid or ambiguous", two jobs in that window "might overlap", and Microsoft suggests avoiding it entirely.

The page then works two daily jobs in US Central time through both 2019 changes. The 1:30 job is untouched. The 2:30 job runs at 3:30 local on the transition day itself, once, then settles back. The stated intent is that both keep "running at the expected local times without skipped or duplicate runs".

Those tables describe Microsoft's engine. No other vendor here publishes an equivalent, and assuming the others behave the same way is the mistake this article exists to correct.

If a run goes missing, is it caught up or lost?

Lost, in most default configurations. Microsoft documents a split between two trigger types, n8n documents catch-up with a list of conditions attached to it, and Zapier and Make publish no answer at all. That leaves an owner unable to say in advance whether the invoice run that did not happen on Sunday morning ever happens.

Microsoft's split is plain. The Recurrence trigger "doesn't process the missed recurrences but restarts recurrences with the next scheduled interval". The Sliding Window trigger "goes back and processes the missed recurrences". A scheduled cloud flow uses Recurrence, so check whether Sliding Window is available to you before planning around it.

n8n's default is to discard, and it says so in the name of the setting: "Don't Run Missed Executions (default): Discard missed executions and resume on schedule." Two catch-up options sit beside it, under conditions n8n prints below them. "These options are available from n8n 2.36, on Schedule Trigger nodes added from that version on. They take effect only when the instance runs the durable scheduler; the default in-memory scheduler never runs missed executions."

Switching it on takes two settings rather than the one you would expect, and the failure mode of getting it half right is quiet. Enable the scheduler alone and n8n "logs a warning and Schedule Trigger nodes keep running on the in-memory scheduler". Even with catch-up on, "the schedule's clock advances past the backlog".

For n8n Cloud there is a gap. That page sits in the self-hosting section and describes settings a Cloud customer cannot reach, and nothing I found states which scheduler Cloud runs. Zapier's nearest statement is a tolerance rather than a recovery: "Zapier does not guarantee your Zap will trigger at the precise minute you set."

Where do the vendors contradict themselves?

In two places, and both matter before you trust an answer from a forum. Zapier's help page and a Zapier staff post disagree about which timezone a schedule uses. On Power Automate, the forum and the documentation disagree about whether the clock change is handled for you at all.

Zapier's help page says schedules use the account timezone, "not the timezone set in your Zap". In December 2024 a Zapier community manager posted the accepted answer on a bug thread saying the opposite: "Now Schedule by Zapier triggers will use the timezone set for the Zap, or your account, rather than defaulting to UTC." Both statements were live in August 2026, so set both timezones and confirm with a real run.

Power Automate is messier. Its community forum carries answers in both directions, that the clock change is handled automatically and that it is not, none of them citing documentation, and Microsoft's own pages say to adjust the recurrence by hand. Forum opinion with no documentation behind it is weaker than the vendor pages above, so the honest summary is narrower than a verdict. Three of the four vendors do not publish an answer, and the one that does asks you to adjust the schedule yourself.

What actually stops the drift?

Seven things, in descending order of how well each is sourced. The first four are documented by a vendor. The last three are workarounds.

Use a named location, never a fixed offset. Microsoft's whole mechanism is the time zone you select. n8n changed its labels for the same reason: the timezone display names now show only the location, because the old offsets were static values that stop being true twice a year.
Avoid start times between 2:00 and 3:00 in the morning. Microsoft's instruction, and the reasoning applies to anything on a local clock. A nightly job at 2:30 lands in an hour that either does not exist or happens twice.
On Microsoft, prefer Sliding Window where a skipped run costs money. Documented: it replays missed runs and Recurrence does not. Check what your own flow can use first.
On self-hosted n8n, turn on the durable scheduler and choose a misfire policy. Documented, with a version floor and two settings. The options appear only on Schedule Trigger nodes added from 2.36 on, so an upgraded instance may still need the node re-added. No policy replays a backlog run by run.
Put machine-facing jobs on a zone that never changes. A zone with no daylight saving, such as UTC, runs at a fixed time year-round. The job then sits an hour from your clock for half the year. Sensible for an overnight sync. Wrong for an 8am customer reminder.
Restart the instance after the clocks change, if you self-host. A workaround rather than a documented fix: it clears whatever the in-memory scheduler computed before the transition, and nobody has published a test of it.
Read the run history on the Monday after. Nothing documented lets you skip this. On Zapier there is a wrinkle: run timestamps in Zap history "display in UTC", so the history will not show you local time.

One tempting fix deserves a warning. Editing the schedule twice a year is what that Zapier customer ended up doing. On n8n it has a side effect, because "the schedule begins from the time when you publish the workflow". Change a two-hourly job at half past eleven and its next run is half past one.

Then put four checks in the calendar for the Monday after each change. Read the run history of every customer-facing job. Ask one person what time their scheduled message arrived. Check one daily report against the day it claims to cover. Write down what you changed, because the next test of it is six months away.

Which of your jobs actually care about the hour?

Fewer than you would guess, and sorting them takes ten minutes. Customer-facing messages tied to a set time care a great deal. Reports that summarise yesterday care, because an hour of drift changes which day the window covers. Internal syncs that run every hour anyway do not care at all.

Reaches a person at a set time. Appointment reminders, opening-hours messages, morning digests for staff. An hour early is a customer complaint, and cutting appointment no-shows depends partly on when the message lands.
Covers a period. Daily sales reports, timesheet exports, anything asking another system for yesterday. Drift moves the boundary, so the figures change without any single figure being wrong.
Just needs to happen. Backups, catalogue syncs, cache warming. Put these on a fixed zone.

Only the first two piles are worth the work described here. If a job fits none of the three, ask whether it should run at all, which is one of the tests in when not to automate a process.

Note who can change the account or organisation setting, too. That person controls the timing of every job you run, which puts it on the same list as the logins, in the automation handover checklist.

None of this needs you to understand offsets, and none of it needs a developer. An automation running at the wrong time after daylight saving is fixed by somebody deciding which jobs care about the hour, and that decision is the whole job. If you would rather have it made for you across everything in your week that repeats, that is what the process audit produces in writing.