If you rely on an n8n schedule trigger timezone to hit the right hour, the bug won’t show up when you build it—it shows up twice a year, and it looks like n8n broke. I’ve seen this personally on our own production schedules. One workflow prepares a report at 10:00 Asia/Karachi, the other sends it at 09:00 US Eastern. The tempting shortcut is to convert both to UTC in your head once and hardcode the cron. That’s wrong in a way that’s invisible for months. Pakistan doesn’t observe daylight saving; the US does. A UTC cron that’s correct in August is an hour off in November, then drifts back in March. Nobody debugs this at the time because the workflow still runs and succeeds—just at the wrong hour.
This guide is a concrete, first-hand breakdown of why the drift happens, how to fix it with the workflow-level timezone setting, and when you can safely stay on UTC. No marketing, no fluff—just the setting that saves you from a support ticket you’ll have to explain twice a year.
Why Hardcoded UTC Crons Fail Twice a Year
The answer: daylight saving is a timezone responsibility, not a UTC responsibility. When you translate a human-meaningful local time into a fixed UTC expression, you freeze the offset. A 0 14 * * * cron that means “10:00 AM Asia/Karachi (UTC+5)” in August is correct until November, when US Eastern falls back and your 9:00 AM send slot suddenly shifts an hour late. The workflow still runs—and still reports success—but the business hour you intended is gone. You only notice when a recipient asks “why did this arrive at 10:00?”
Our two scheduled n8n workflows run on slots defined in different regions: prepare at 10:00 Asia/Karachi, send at 09:00 US Eastern. Pakistan has no DST, so that slot is simple in UTC all year. But the US slot is not. A single hardcoded UTC cron can’t serve both. I’ve watched teams deploy this, close the ticket, and only catch the drift months later—usually after the second shift. The fix is straightforward: stop doing the DST arithmetic yourself and let n8n do it on every fire.
Setting the n8n Schedule Trigger Timezone Correctly
The fix: set the timezone per workflow, write the cron in local time, and let n8n compute the UTC fire times automatically. Here’s the playbook:
- Open the workflow in the n8n editor.
- Click the Settings tab (the gear icon) on the left sidebar.
- Find the Timezone dropdown—it defaults to the instance-level fallback (more on that in a moment).
- Select the IANA timezone that matches the business intent of the schedule:
America/New_Yorkfor US Eastern,Asia/Karachifor Pakistan, etc. - Write your cron expression in that local time. For a 9:00 AM US Eastern send, the cron becomes
0 9 * * *—no mental UTC conversion required.
Now n8n recalculates the absolute UTC moment every time it evaluates the schedule. When daylight saving starts or ends, the offset changes automatically. The workflow keeps firing at 9:00 AM wall-clock time, and you never touch the cron again.
Crucially, this is a workflow-level setting, not a global crutch. The instance-level default (the GENERIC_TIMEZONE environment variable) is just a fallback for workflows that don’t specify one. If you run schedules for more than one region on one instance—exactly our case—you must set the timezone on each workflow individually. The fallback can’t guess which region a particular cron belongs to.
When to Use UTC vs Local Time
Our own rule after getting burned:
- Any cron tied to a human hour (a send slot, a business-hours alert, an end-of-day report, a time‑sensitive customer message) gets an explicit workflow timezone.
- Any cron that just needs to happen every N hours (a housekeeping task, a sync that doesn’t care about wall clock, a heartbeat) can stay on UTC.
The litmus test: “If this runs an hour earlier or later during DST transitions, does a human on the other end notice?” If yes, set the timezone.
This pattern saves a lot of headaches when you’re building production-grade n8n automations that span multiple regions or serve distributed teams. Timezone‑aware scheduling is one of those details that separates a prototype from something you can trust without watching the logs every spring and autumn.
Common Misunderstandings and One Hard-Won Rule
The environment variable GENERIC_TIMEZONE often causes confusion. It does change the default timezone shown in new workflow settings, but it doesn’t touch any workflow that already has a timezone stored in its JSON. If you inherit an n8n instance from a teammate or deploy a shared instance, check every schedule trigger’s timezone individually. I’ve seen workflows imported from a community template that still run on UTC because the creator never touched the dropdown.
Also, if you’re comparing n8n’s scheduler with other tools (say, n8n vs Make), the timezone handling in n8n is explicit per workflow in the core settings, not buried in an advanced expression block. That visibility helps enforcement. We’ve made it a rule: any code review that touches a Schedule Trigger node must confirm the timezone dropdown matches the documented intent of the trigger. It’s a small check that prevents a silent drift.
If you’re running a multi-client automation setup, this per‑workflow discipline scales—our n8n automation agency now treats timezone mismatches as a hard fail in onboarding audits.
FAQ
Why does my n8n workflow run at the wrong time after daylight saving changes?
Because you hardcoded a UTC cron instead of setting the workflow’s timezone to the local hour you actually care about. n8n can handle DST automatically if you choose the right timezone in the workflow settings and write the cron in local time.
How do I set the timezone for an n8n schedule trigger?
Open the workflow settings (the gear icon), pick the target IANA timezone from the dropdown, and write the cron in that local time. n8n will recalculate the equivalent UTC fire times on every evaluation, accounting for DST automatically.
Can I set a default timezone for all my n8n workflows?
Yes, via the GENERIC_TIMEZONE environment variable, but it’s only a fallback for workflows that haven’t chosen an explicit timezone. If your instance hosts schedules for multiple regions, you still need to override the timezone on each relevant workflow.
