Time shown in Workflow executions is UTC

[Miguel_in]

Describe the problem/error/question

Hi guys,
I have n8n Communuty running self-hosted as docker container in Synology NAS. Current version deployed is 2.6.3.
I noticed that a scheduled workflow is being executed one hour before than planned and the Executions log is showing the UTC time instead of my TIMEZONE define.
I have this in my compose environment section:
GENERIC_TIMEZONE: Europe/Madrid
TZ: Europe/Madrid
In addition I tried to use aswell:
N8N_TIMEZONE: Europe/Madrid
Same results.
There is no errors, just a quite “complicated” to read some logs.
Thanks

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[tamy.santos]

Hi @Miguel_in

You need to explicitly set the workflow timezone to Europe/Madrid.

After any change, deactivate and re-activate (publish) the workflow. This step is mandatory because the Schedule Trigger only recalculates execution times when the workflow is published again.

If it still runs one hour early after that, the documentation does not describe any additional n8n-side causes. In that case, the most likely explanation is DST (daylight saving time) or how the host/Synology system timezone is configured, not an issue with n8n itself.

If you need to see timestamps in local time, they must be explicitly converted or formatted inside the workflow, as execution logs are shown in UTC by design.

[Miguel_in]

Hi @tamy.santos

Workflow timezone is defined to Default - Europe/Madrid as well.

One question, do you mean that Execution Logs seen in the Executions tab are always shown in UTC or do you mean in LOG files?

Regards

[tamy.santos]

@Miguel_in

The Executions tab always shows timestamps in UTC by design, and the UI does not convert them to the workflow or system timezone. The Schedule Trigger itself respects the timezone configured at the workflow level, as long as the workflow is republished after any change.

Once that is correctly set, the documentation does not describe any n8n-side reason for a consistent one-hour offset. In practice, this usually points to daylight saving time (DST) or the host/container timezone configuration rather than an issue with n8n itself.

[Miguel_in]

Thanks @tamy.santos

I just checked that the workflow is triggered at correct timezone. It is only in N8N UI where I see the UTC time instead of timezone defined.

So I think this is correct by design as far as I understand.

Regards

[tamy.santos]

@Miguel_in

I’m really happy to hear this helped
If this solution solved the issue for you, please consider leaving a like or marking the reply as the solution, it helps others find the answer more easily and also supports community contributors.

Regards.

[Press]

Hi everyone,

I’d like to share an observation that looks like a regression in execution timestamps introduced after n8n 2.4.5, and see if anyone else can confirm this.

⸻

Setup

•   Self-hosted n8n (Docker)

•   PostgreSQL

•   Reverse proxy (Traefik)

•   Timezone: Europe/Moscow (UTC+3)

•   Environment variables:

GENERIC_TIMEZONE=Europe/Moscow

TZ=Europe/Moscow

•   Same host, same DB, same workflows

Observed behavior

n8n 2.4.5

•   Execution startedAt matches real local time

•   Execution duration is correct (milliseconds / seconds)

•   UI, DB records, and real execution time are consistent

Example:

Feb 9, 02:24:55

Succeeded in 9ms

Everything is stable and correct.

n8n 2.5.x – 2.6.4 (latest)

•   Execution startedAt is consistently shifted by –3 hours

•   Looks like UTC is stored but interpreted/displayed as local time

•   Results in:

•   incorrect execution start time

•   misleading execution durations (sometimes \~3h)

•   This happens consistently, not randomly

Same workflow, same input, same environment — only the image version changes.

⸻

Important clarification

•   This is not about Schedule Trigger firing at the wrong time

→ triggers execute at the correct local time.

•   This is not about logs formatting only

•   This is specifically about:

•   execution startedAt

•   execution duration

•   UI execution timestamps vs real time

⸻

Why this looks like a regression

•   2.4.5 behaves correctly and consistently

•   No timezone hacks or conversions needed

•   From 2.5+ onward, timestamps are always offset by exactly the timezone difference (UTC vs local)

This suggests a change in how execution timestamps are stored and/or interpreted between backend and UI.

⸻

Current workaround

For now, staying on 2.4.5, since newer versions make execution timestamps unreliable for monitoring and reporting.

⸻

Questions

1\.  Is this a known regression introduced after 2.4.x?

2\.  Has execution timestamp handling changed intentionally in 2.5+?

3\.  Is there a recommended way to restore correct local execution start times (not just trigger correctness)?

Happy to provide DB samples (startedAt, stoppedAt) if needed.

Thanks!

[Press]

Additional findings after deep investigation (confirmed regression)

After further debugging, I can confirm that this is not a database, Docker, or host timezone issue, but a regression in n8n versions ≥ 2.5.x affecting execution timestamps in the UI.

Environment

•   n8n Docker (self-hosted)

•   PostgreSQL (timestamp with time zone)

•   Host timezone: Europe/Moscow (UTC+3)

•   Container timezone:

•   TZ=Europe/Moscow

•   GENERIC_TIMEZONE=Europe/Moscow

•   Database timezone:

SHOW timezone*;*

-- Europe/Moscow

Database behavior (verified correct)

PostgreSQL behaves exactly as expected:

SELECT

now() AS now_tz,

now() AT TIME ZONE 'UTC' AS now_utc,

current_setting('TimeZone') AS tz*;*

Result:

•   now_tz → local time with +03:00

•   now_utc → correctly shifted −3h

•   timezone → Europe/Moscow

Execution records are stored correctly:

SELECT

id,

“startedAt”,

“startedAt” AT TIME ZONE ‘UTC’ AS started_utc,

“startedAt” AT TIME ZONE ‘Europe/Moscow’ AS started_msk

FROM execution_entity

ORDER BY id DESC

LIMIT 3*;*

SELECT

id,

“startedAt”,

“startedAt” AT TIME ZONE ‘UTC’ AS started_utc,

“startedAt” AT TIME ZONE ‘Europe/Moscow’ AS started_msk

FROM execution_entity

ORDER BY id DESC

LIMIT 3*;*

Example:

startedAt = 2026-02-09 06:56:43 +03:00

started_utc = 2026-02-09 03:56:43

started_msk = 2026-02-09 06:56:43

Data in the database is correct and consistent.

⸻

Observed behavior

n8n version

Execution start time in UI

2.4.5

Correct (local time)

2.5.x – 2.6.4

Displayed as UTC (−3h offset)

•   Execution duration is correct

•   Schedule triggers fire at the correct local time

•   Only the Executions UI timestamp is wrong

•   The UI appears to display startedAt as UTC without converting from the stored timezone

This happens for:

•   Webhook triggers

•   Manual executions

•   Scheduled workflows

⸻

Key conclusion

This is not expected “Executions are always UTC” behavior:

•   The database stores timestamp with time zone

•   n8n ≤ 2.4.5 rendered execution timestamps correctly

•   n8n ≥ 2.5.x consistently renders them as UTC

This strongly indicates a frontend or backend regression in execution timestamp handling introduced after 2.4.5.

⸻

Repro steps (minimal)

1\.  Run n8n 2.4.5 → execution times match local timezone

2\.  Upgrade to 2.6.x (same DB, same container, same env vars)

3\.  Run any workflow

4\.  Observe execution start time shown −3h (UTC) in UI

5\.  Downgrade back to 2.4.5 → issue disappears

⸻

If this change was intentional, it would be helpful to:

•   Clarify it explicitly in documentation as a breaking UI change

•   Or provide a setting to render execution timestamps in workflow/system timezone

Happy to provide logs, screenshots, or test data if needed.