The Workflow That Ran at 3 AM: Timezone Bugs in Scheduled n8n Workflows

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

В n8n‑workflow, запланированном на 9 AM без указания часового пояса, из‑за перехода на летнее время и разницы между сервером (UTC) и бизнес‑часовой зоной, задача выполнилась в 3 AM, отправив устаревший отчёт.

Задача

A scheduled n8n workflow that was intended to run at 9 AM local time ran at 3 AM UTC, delivering stale data and missing the intended audience.

Результат

The workflow ran successfully but at the wrong hour, causing delayed and stale reports.

Рабочий процесс

• 1. Schedule workflow with cron expression for 9 AM without timezone. 2. Server runs in UTC. 3. Daylight saving transition shifts business timezone by one hour. 4. Workflow executes at 3 AM UTC, producing stale summary.
• 5. Summary sent to recipients at 3 AM, unread until noon.

Доказательства

A client workflow sent a daily summary every morning at 9 AM. It ran perfectly for months, and then one Monday the summary arrived at 3 AM, woke nobody up, and sat unread until noon — by which time the numbers in it were already stale.

Источник

What had changed was the clock underneath it. The server ran in UTC, the business ran in another timezone, and a daylight saving transition moved the two apart by an hour.

Источник

Timezone bugs in scheduled workflows are quiet in exactly the way production bugs love: the workflow runs, it succeeds, it produces output — just at the wrong hour, for the wrong day, against the wrong date boundary.

Источник