By default, n8n runs in America/New_York instead of Europe/Berlin. Here is how to correctly set GENERIC_TIMEZONE and the workflow timezone.
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.
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).
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).
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.
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.
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.
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.
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.
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.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
The most practically relevant n8n environment variables for German self-hosting setups: host, webhook URL, timezone, security, and database at a glance.
n8n isn't always the right choice. These scenarios honestly show when cloud limits, governance, or operations speak against it.
The cron expression is almost always correct, the timezone is not. Three real n8n forum cases show why Schedule Triggers fire at the wrong time.
GENERIC_TIMEZONE and per-workflow timezone settings are easy to get wrong, especially once several people work on the same instance. NordFlux runs your n8n instance as a managed service and keeps schedules, cron triggers and system time properly aligned. In an initial conversation we review your current configuration.
