Potential Bug in v2.6.4: Wait node fails on long intervals (5min) but works on short ones (60s)

Questions
1

Hi everyone,

I’m reporting a strange behavior in version 2.6.4. I haven’t seen anyone else mentioning this yet, so I’m not sure if it’s a bug or something wrong with my setup, but here are my findings:

The issue: I have a workflow with Wait nodes. When set to 5 minutes, the workflow stops and never resumes. I tried disabling the “Timeout Workflow” (previously set to 10 min), and the node just stays in “Waiting” status indefinitely until I stop it manually. No errors are logged.

The workaround: I discovered that if I replace the 5-minute Wait node with five consecutive 1-minute (60s) Wait nodes, the workflow completes successfully.

It seems like there is an issue when the Wait node tries to persist the execution to the database for longer intervals, whereas short intervals (staying in memory) work fine.

I am using a self-hosted Docker setup with Postgres. Any guidance would be appreciated.

Debug info:
Debug info

core

  • n8nVersion: 2.6.4
  • platform: docker (self-hosted)
  • nodeJsVersion: 20.19.0
  • nodeEnv: production
  • database: postgres
  • executionMode: regular
  • concurrency: -1
  • license: enterprise (production)

storage

  • success: all
  • error: all
  • progress: false
  • manual: true
  • binaryMode: filesystem

pruning

  • enabled: true
  • maxAge: 336 hours
  • maxCount: 10000 executions

client

  • userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/144.0.0.0 safari/537.36
  • isTouchDevice: false

security

  • blockFileAccessToN8nFiles: false

Generated at: 2026-02-10T14:45:03.909Z

2

I used a wait node with a time between 5-8 minutes, and it works for me.
That said, my container is not production; it’s only on my laptop.

1 Like
3

Hi @anicolco, welcome back to the community.
This documentation helped me; see if it can help you too.
Time-based ops
Wait > 60s issue
Call WF + Wait
Wait node docs

1 Like
4

Thanks for the suggestions! To clarify: I have another n8n instance running on Ubuntu that works perfectly with this same setup, so the workflow logic is correct.

This issue is specific to my Synology NAS (Portainer stack) and started immediately after updating to v2.6.4. I have already tried restarting the stack, but the problem persists.

5

SOLVED / RESUELTO

Thanks everyone for the suggestions! I found the root cause and solution.

The real problem: The issue wasn’t directly with the Wait node itself, but with the X-Forwarded-For header validation that was introduced in v2.6.4.

When I checked the Docker logs, I found repeated ValidationError messages about the Express trust proxy setting. This was blocking the internal webhooks that the Wait node uses when persistence to database is required (>65 seconds).

The solution: Add these two environment variables to your n8n Docker configuration:

N8N_PROXY_TRUST_ALL: "true"
N8N_METRICS: "true"

After adding these variables and restarting the container, the Wait node now works perfectly with any duration, including 5+ minutes.

Why this happened: If you’re running n8n behind a reverse proxy (Nginx, Traefik, etc.) and upgraded to v2.6.4, the stricter rate-limiting validation requires explicitly trusting the proxy headers.

Hope this helps anyone experiencing the same issue!

Información de depuración actualizada:

  • n8n version: 2.6.4

  • Platform: Docker (Synology NAS via Portainer)

  • Database: PostgreSQL

  • Proxy: Yes (Nginx reverse proxy)

  • Status: :white_check_mark: RESOLVED

3 Likes
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.