Fix: n8n schedule trigger firing at the wrong timezone

    Your scheduled workflow fires hours early or late because n8n defaults to UTC. Here's the fix and the DST gotcha that breaks it twice a year.

    Last updated 2026-06-08~4 min read
    n8nSchedule TriggerCron

    Symptoms — what you're seeing

    • Your Schedule Trigger fires at the wrong time — usually off by a few hours
    • A workflow set to run at 9:00 AM your local time fires at 9:00 AM UTC instead
    • Scheduled workflows that worked correctly suddenly shifted after a daylight saving time change
    • The execution log shows the workflow ran, but the timestamp doesn't match what you configured
    • Different workflows on the same instance fire at different timezone offsets

    Why this happens

    The n8n Schedule Trigger node uses the timezone set on the node itself, not your browser timezone, not your server timezone, and not the timezone in your n8n settings. If you don't explicitly set the timezone on the Schedule Trigger node, it defaults to UTC — regardless of where your server is physically located or what timezone your browser reports.

    This catches almost everyone the first time. You configure "run at 9:00 AM," you're in EST (UTC-5), and the workflow fires at 2:00 PM your time because n8n interpreted 9:00 AM as UTC.

    The second common cause is daylight saving time (DST). If you set your timezone to a region that observes DST (like America/New_York), the UTC offset changes twice a year. A workflow running at 9:00 AM EST will shift to 10:00 AM EDT — or vice versa — unless you're using a timezone identifier that handles DST automatically (like America/New_York instead of EST).

    The fix, step by step

    1. Open the Schedule Trigger node in your workflow editor. Look for the Timezone field — it's in the node parameters, not in the global settings.
    2. Set it to your IANA timezone identifier. Use the full region name, not the abbreviation:
      # Correct — handles DST automatically
      America/New_York
      Europe/London
      Asia/Karachi
      Australia/Sydney
      
      # Wrong — these are fixed offsets, they don't adjust for DST
      EST
      GMT+5
      UTC-4
    3. Save and re-activate the workflow. The timezone change only takes effect after you save. If the workflow was already active, deactivate it, save, then reactivate.
    4. Verify in the execution log. After the next scheduled execution, check the timestamp in the execution list. It should now match your expected local time.

    For self-hosted instances

    You can also set a default timezone for your entire n8n instance using the GENERIC_TIMEZONE environment variable. This affects the default timezone for new Schedule Trigger nodes, but doesn't override nodes where the timezone is already explicitly set.

    # .env or docker-compose.yml
    GENERIC_TIMEZONE=America/New_York

    Common variations

    • "Workflow fires an hour early/late after March or November" — DST shift. You're using a fixed offset (EST, UTC-5) instead of an IANA identifier (America/New_York). Switch to the IANA name.
    • "Workflow fires at the right time on n8n Cloud but wrong time on self-hosted" — the self-hosted instance's system clock or Docker container timezone is set incorrectly. Check with date inside the container. The fix is setting GENERIC_TIMEZONE in your env.
    • "Cron expression fires correctly but interval trigger doesn't" — the interval trigger ("every 30 minutes") starts counting from when the workflow was last activated, not from midnight. If you activate at 2:17 PM, it runs at 2:47 PM, 3:17 PM, etc. Use a cron expression for clock-aligned schedules.
    • "Multiple Schedule Triggers in one workflow fire at different times" — each Schedule Trigger node has its own timezone setting. Check every trigger node in the workflow individually.

    When this isn't the issue

    • If the workflow doesn't fire at all (not just at the wrong time), check that it's activated — the toggle must be ON and the workflow saved
    • If the workflow fires at the right time but processes stale data, the issue is in your data-fetching logic, not the trigger timing
    • If you're on n8n Cloud and the timezone field shows the correct value but still fires wrong, contact n8n support — there have been occasional timezone bugs in specific n8n Cloud regions

    For more on running n8n reliably in production, see the n8n production reliability checklist.

    Browse 4,900+ ready-to-import workflow templates →

    Need this workflow customized or debugged? Book a 30-min scope call →

    Stuck configuring this workflow?

    I build and fix n8n workflows for agencies and SaaS teams. 30-minute scope call — bring the problem, leave with an estimate.

    Related pages

    Related workflows