My 9 AM Workflow Ran at 1 AM: The Timezone Bug That Only Strikes in Production

说明与用途

在生产环境中，n8n 工作流按 9 AM 调度，但因容器使用 UTC 时区而在 1 AM 触发，导致客户收到错误时间的摘要。解决方案是将 GENERIC_TIMEZONE 设置为受众时区，并添加记录实际执行时间的检查节点。

问题

A scheduled n8n workflow that should run at 9 AM local time executed at 1 AM UTC, sending digests to clients at the wrong time and using stale data.

结果

The workflow now reliably runs at the intended local time, sends digests on schedule, and uses correct data.

工作流

• Set GENERIC_TIMEZONE=Asia/Shanghai in deployment environment
• Configure Schedule Trigger cron expression in audience’s timezone
• Add a guard node: Schedule Trigger → Set (log execution_time: {{ $now.toFormat('yyyy-MM-dd HH:mm z') }})
• Verify first real run logs the expected time
• Ensure date calculations use the pinned timezone
• Avoid scheduling between 1:00–3:00 AM in DST‑observing zones

证据

The Schedule Trigger was set to 9:00. The executions list said 9:00. And yet the email landed at 1:00 AM local time.

来源

n8n evaluates Schedule Trigger cron expressions in the timezone of the machine (or container) it's running on.

来源

I now set it explicitly in every deployment: GENERIC_TIMEZONE=Asia/Shanghai

来源

Every scheduled workflow I ship now starts with a two-node guard: Schedule Trigger → Set (log execution_time: {{ $now.toFormat('yyyy-MM-dd HH:mm z') }})

来源