Configuring cron and Schedule Trigger correctly in n8n: the timezone is almost always to blame

The cron expression in the Schedule Trigger is almost always correct. What usually is not correct in practice is the timezone in which n8n evaluates this expression. This exact pattern runs through three real threads in the n8n forum that we look at in detail in this article: a team in queue mode, a user in Brazil, and a user in London who was puzzled by a one hour difference even though his workflow setting was set to GMT. In all three cases the cron expression itself was correct, the cause was one level deeper.

According to the official Schedule Trigger documentation the node uses a timezone hierarchy with several levels, and this is exactly where most surprises arise. If you understand how n8n resolves these levels, you can avoid almost all timezone bugs before they even go live. As of: July 2026.

How the Schedule Trigger interprets cron expressions

In custom mode, the Schedule Trigger accepts, according to the documentation, a classic cron expression with six fields, where the sixth, optional field represents seconds, followed by minute, hour, day of month, month, and day of week. The documentation lists a reference table with common patterns for this:

• Every X seconds: `*/10 * * * * *`
• Every X minutes: `*/5 * * * *`
• Hourly: `0 * * * *`
• Daily: `0 6 * * *`
• Weekly: `0 12 * * 1`
• Monthly: `0 0 1 * *`

For testing, n8n itself recommends checking an expression beforehand on crontab.guru, though without the optional seconds column, because this tool only knows five fields. This step alone helps you rule out syntax errors before you even get into the timezone pitfalls. The expression itself is unremarkable in almost every one of the publicly discussed issues, the problem only starts afterward, with the question of which timezone n8n actually evaluates this expression in.

The timezone hierarchy: instance, workflow, and worker

n8n sets a clear order of precedence for the timezone. If a timezone is set in the workflow itself, that one applies. If it is missing, n8n falls back to the instance timezone. For self hosted instances, the default value is not UTC or the timezone of your server, but according to the documentation `America/New_York`. On n8n Cloud, the system tries to automatically detect the timezone of the account holder, but falls back to GMT if detection fails.

The page on common issues of the Schedule Trigger describes exactly this mechanism as the most common source of error and names two adjustment points: at the workflow level, the timezone can be adjusted via the three dots at the top right of the canvas, then Settings, and the Timezone parameter. Globally, for the whole instance, on self hosted installations you instead set the environment variable `GENERIC_TIMEZONE`. Important here: this variable affects the instance, not automatically every single process that belongs to this instance, as the first case below shows.

Three real cases from the n8n forum

Case 1: queue mode, configured correctly, still wrong

In the thread "Schedule Trigger executing at wrong time" a user describes a weekly trigger that was supposed to run on Sundays at 3 AM PST but actually fired at 7 PM. Both the workflow setting and the installation timezone were correctly set to PST, an old cron node even ran in parallel without errors. The user found the solution themselves: "We use n8n in queue mode - and it turns out, I forgot to set the timezone parameters on the workers!!!" The main instance had the correct timezone, but the separate worker pods in Kubernetes did not. After setting the TZ environment variable on the worker deployments, the test workflow ran "on the dot", as the user confirmed. Anyone running n8n in queue mode must therefore set the timezone on every single component, not just on the main instance.

Case 2: Brazil and the silent default value

In the thread "Schedule Trigger - what's the time zone?" a user from Brazil (UTC-3) reports a difference of exactly two hours: a trigger scheduled for 11 AM fired at 1 PM instead. The cause was simply the unoverwritten default value `America/New_York`, which n8n applies to self hosted instances when no one explicitly configures anything else. Two ways were mentioned as a solution, either changing the timezone directly in the workflow via Settings, or setting it globally via `GENERIC_TIMEZONE` in the Docker Compose file or in the Docker image. Anyone setting up a fresh n8n installation should therefore think about this variable from the start, instead of adding it only after the first incorrectly triggered run.

Case 3: London, daylight saving time, and the misunderstanding around GMT

In the thread "Schedule Trigger and Confusion Over Time Zone Settings" user kpakfar was puzzled by a one hour difference between `DateTime.now()`, which correctly displayed London time including daylight saving time, and the Schedule Trigger, which apparently ran according to the setting labeled GMT. Community member ihortom clarified that the trigger was working correctly according to London time, not according to the literal label "GMT 00:00". The hint here: anyone who really wants a fixed timezone without a daylight saving switch must explicitly select "(GMT+00:00) GMT (no daylight saving)". The normal, city linked timezone option accounts for daylight saving time automatically, even if its label does not reveal that at first glance. Anyone who needs fixed UTC times independent of daylight saving time, for example for systems that themselves speak UTC, should specifically choose the variant without daylight saving instead of a city based timezone.

How to set up the timezone reliably

• Check the cron expression separately: Test the pure syntax beforehand on crontab.guru, without the optional seconds field, before you deal with the timezone.
• Set the workflow timezone explicitly: Do not rely on the instance default, but enter the timezone in the workflow settings, especially with several workflows for different target audiences or countries.
• Set `GENERIC_TIMEZONE` for self hosting: Without this variable, your instance defaults to `America/New_York`, regardless of where your server actually runs.
• Queue mode: do not forget the workers: Set the timezone on every worker deployment individually, a correctly configured main instance alone is not enough there.
• Decide on daylight saving time deliberately: Choose a city based timezone if daylight saving time should be applied automatically, or a fixed variant without daylight saving if you need an exact UTC time independent of the season.

At NordFlux, we set up n8n workflows so that cron triggers run in the correct timezone from the start, whether on a single instance or in queue mode with multiple workers. This keeps time critical automations reliable, and you retain control over when your digital workers actually kick in. You can find more about our approach at n8n automation by NordFlux.

Frequently asked questions

Why does my cron trigger run at the wrong time even though the expression is correct?

In the vast majority of cases, it is not the cron expression itself, but the timezone in which n8n evaluates it. First check the workflow settings, then the instance timezone, and in queue mode additionally the timezone on every worker.

What is the default timezone of n8n if I do not set anything?

For self hosted instances, the default value according to the documentation is `America/New_York`. On n8n Cloud, the system tries to automatically detect the timezone, and falls back to GMT if detection fails. Both default values rarely coincidentally match your actual timezone.

How do I set the timezone for a single workflow?

Open the workflow in the canvas, click the three dots at the top right, choose Settings, and adjust the Timezone parameter. This setting overrides the instance timezone only for this one workflow.

Do I need to consider anything additionally in queue mode?

Yes. The timezone setting of the main instance is not enough in queue mode, because triggers are executed on separate worker processes. Set the appropriate TZ environment variable on every worker deployment, otherwise the main instance can be correctly configured and the trigger can still fire at the wrong time.

How do I avoid surprises caused by daylight saving time?

A city based timezone like London or Berlin automatically adjusts to daylight saving and standard time. If you instead want a fixed time independent of the season, explicitly choose a timezone option without daylight saving, instead of relying on the label alone.