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

Description and use

An n8n workflow scheduled for 9 AM without a timezone ran at 3 AM UTC after a daylight saving shift, delivering a stale daily summary.

Problem

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.

Outcome

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

Workflow

• 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.

Evidence

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.

Source

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.

Source

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.

Source