Wrong Times in n8n: Setting UTC, GENERIC_TIMEZONE and Cron Correctly

Wrong times in the Schedule Trigger node are almost always caused by the n8n timezone, not by the cron expression itself. Without any configuration, according to the official documentation, n8n uses the timezone America/New_York by default, not Europe/Berlin, which causes scheduled workflows to start several hours away from the expected time. There are two settings that work independently of each other: the instance-wide environment variable GENERIC_TIMEZONE for self-hosted installations, and a separate timezone setting per workflow that overrides the instance value. As of: July 2026.

Why does my n8n workflow start at the wrong time?

The most common reason is that neither the instance nor the individual workflow has a timezone set, so n8n falls back to the default value America/New_York. For example, you enter 09:00 in the Schedule Trigger node meaning Europe/Berlin, while n8n interprets the input as 09:00 New York time. Depending on daylight saving or standard time, this results in a shift of five to six hours compared to the desired German time. According to the troubleshooting notes for the Schedule Trigger node, this is exactly the typical cause when workflows run "at wrong times", and the documentation points directly to the timezone configuration as the first solution step (n8n Docs: Schedule Trigger, Common Issues).

How do I set the timezone for the entire n8n instance?

For self-hosted installations, you set the environment variable GENERIC_TIMEZONE to the desired value, for example Europe/Berlin, thereby defining the default timezone for the entire instance. According to n8n documentation, this variable is "important for schedule nodes (such as Cron)" and defaults to America/New_York if not specified (n8n Docs: Set the timezone for self-hosted n8n).

• GENERIC_TIMEZONE: Environment variable that sets the default timezone for the entire self-hosted n8n instance, for example via export GENERIC_TIMEZONE=Europe/Berlin.
• Valid values: IANA timezone identifiers such as Europe/Berlin, not simple abbreviations like CET.
• n8n Cloud: Here there is no environment variable, but rather a timezone selection under Dashboard, Manage and the Timezone dropdown, which also affects the Schedule Trigger and the Date & Time node (n8n Docs: Set your timezone in n8n Cloud).

How do I set the timezone for just a single workflow?

Each workflow can have its own timezone, which takes priority over the instance setting for that workflow. To do this, open the workflow, click the three-dot menu in the top right, select Settings and set the desired zone in the Timezone field before saving. According to the documentation, this setting is "important for the Schedule Trigger node" and is suitable for cases where individual automations should deliberately run in a different timezone, for example for customers or locations outside Germany (n8n Docs: Configure workflow settings).

The order is as follows: n8n first uses the workflow timezone if set, otherwise the instance timezone from GENERIC_TIMEZONE, and only if both are missing, the default value America/New_York. Anyone running multiple workflows with German customers therefore saves repeated manual work by setting GENERIC_TIMEZONE once instance-wide to Europe/Berlin instead of changing each workflow individually.

How do I recognize that a scheduling error is really caused by the timezone?

A clear indication is when a workflow consistently triggers a fixed number of hours away from the expected time, or when the behavior changes after the daylight saving time change, since both point to an incorrect or missing timezone setting rather than a faulty cron expression. First check the cron expression itself against crontab.guru and make sure it follows the six-column syntax including seconds expected by n8n. It is also important that changes to schedule variables or the interval, according to the documentation, only take effect after the workflow is republished, with the schedule then counting again from the republish time, which can also lead to seemingly incorrect first executions.

If you already operate several n8n workflows for customers or within your own company and would like timezones, cron logic or entire automation chains set up cleanly, NordFlux handles the technical setup as part of the n8n Automation at a fixed price, including handover of the configuration to you.

Frequently Asked Questions about n8n Timezones

What is the difference between GENERIC_TIMEZONE and the workflow timezone?

GENERIC_TIMEZONE is an environment variable that sets the default timezone for the entire self-hosted n8n instance. The workflow timezone, on the other hand, is set in the settings of an individual workflow and overrides the instance value for that specific workflow. If neither is set, n8n falls back to America/New_York according to the documentation.

Which timezone does n8n use if I don't set anything at all?

Without any configuration, n8n uses America/New_York by default, which the documentation also refers to as the EDT timezone. This mainly affects the Schedule Trigger node and the Date & Time node and typically results in a shift of five to six hours for German users compared to Europe/Berlin.

Do I need to reactivate the workflow after a timezone change?

Yes, changes to schedule variables and intervals, according to n8n documentation, only take effect after the workflow is republished. The schedule counts again from this republish time, so the first execution after a change may occur at a different time than expected. Therefore, check after every timezone adjustment whether the workflow was actively saved.

Does GENERIC_TIMEZONE also apply to n8n Cloud?

No, GENERIC_TIMEZONE is an environment variable for self-hosted n8n installations. For n8n Cloud, you set the instance timezone instead via the Dashboard under Manage and the Timezone dropdown. The effect on the Schedule Trigger and Date & Time node is the same in both cases.