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

Описание и применение

В продакшене n8n, запущенном в Docker с TZ=UTC, расписанный на 9 AM cron‑триггер сработал в 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') }})

Источник