I tried with 2.17.2 too, but now, many executions (even debug ones) get stuck on “Waiting nodes”.
They get stuck like this (says waiting in 1.03s, when 11:42 was 4 hours ago):
This is a HUGE bug, as it stops most workflows from ever completing.
I don’t know how waiting nodes are implemented, but it looks like it only checks once, and then it stops updating/checking.
It is indeed an issue with 2.16 and up.
I have reverted back to 2.14.2, and now all the waiting workflows/nodes got updated to this:
It’s either this (version change 2.16→2.14.2 ) or maybe simply the fact that the n8n service was restarted (?)
hi @XCS
Based on what you described, I can’t be certain which one fixed it, but since the waiting executions resumed after the service restart, the restart is the more direct explanation than the downgrade itself.
@XCS that negative execution time (-6719s) is a dead giveaway — the resume timestamp is getting calculated wrong, likely a timezone or clock drift issue between your DB and n8n process. check your GENERIC_TIMEZONE env var matches your system clock and DB server timezone, that expression on the Wait node evaluates at trigger time not resume time so a mismatch there would explain the stuck state exactly
Adding to what the others mentioned, if you are using the default SQLite database and handling a large volume of executions, the database lock can sometimes silently fail to update the “resume” status of Wait nodes under heavy load.
I ran into a similar “ghost waiting” issue a while back. Moving to PostgreSQL completely solved it for me, as it handles concurrent read/writes for the execution logs much better than SQLite. If you are already on Postgres, checking the execution_entity table directly when a node gets stuck might show you if the waitTill column is actually getting written correctly or if it’s an application-level failure like Benjamin suggested
I had a similar issue after upgrading. In my case the problem was the n8n worker process not picking up queued executions properly. A few things that helped:
n8n db:revert and re-run migrations if the schema wasn’t updated cleanlyAlso worth checking the execution_entity table directly - if waitTill is null for stuck executions, it’s likely a worker not picking them up rather than a wait node issue. Hope this helps narrow it down.
Hi all,
This is a regression since 2.16 : URGENT - Wait node "Invalid token" error blocking production workflows after 2.16.1 update · Issue #28632 · n8n-io/n8n · GitHub
Ticket Linear : GHC-7762
I’m stuck at the 2.15 release til this issue is solved by the n8n teams !
Best regards
Same issue, still broken on 2.16.1 (self-hosted, Postgres)
Confirming this is happening for me too. Running n8n 2.16.1 on Synology NAS with a Postgres backend.
Workflow: Instagram auto-poster using Facebook Graph API. The structure is:
Publishing Instagram (POST /media) → Wait node → Post to Instagram (POST /media_publish)
The Wait is there to give Instagram’s servers a few seconds to process the media container before publishing.
Wait node config:
Resume: After Time Interval
Amount: 5
Unit: seconds
So nothing exotic, just a straightforward 5-second pause.
What I see:
The Wait node never resumes on its own. Executions sit in “Waiting” status for hours. When they do finally complete, multiple executions always finish at the exact same millisecond, which tells me they were frozen until something externally (container restart, wait-tracker recovery) released them all at once.
Example from my logs:
Execution A: started 2026-04-19 21:00:55, stopped 2026-04-20 06:26:41. That is 9h 25m for what should be a 5-second wait.
Execution B: started 2026-04-20 06:00:14, stopped 2026-04-20 06:26:41. Same stop timestamp, 3ms apart.
After the forced resume, the first Postgres node downstream of the Wait fails with a generic “Unknown error”, presumably because the stored execution context did not restore cleanly after such a long pause.
Tried so far, didn’t help:
Deactivate and reactivate the workflow
Restart the n8n container
Shorter Wait interval (5s, 10s, 30s, same behavior)
Changing resumeAmount / resumeUnit explicitly via the API (same result, the Wait node is configured correctly)
Looks like the same root cause as GitHub issue #28541, dbTime.getTime is not a function in the wait-tracker poller on the Postgres branch. If that is confirmed, a patch release for the 2.16.x and 2.17.x line would be really welcome, because downgrading to 2.14.2 (as @XCS did) is not an option for everyone once newer schema migrations have run.
Anyone from @n8n able to confirm an ETA on a fix, or a tested workaround that does not require rolling back the DB schema?
Same here…
I have the same issue.
getting something similar to it.
Solved with the 2.18.0 ! Thanks to the dev teams !
Self-hosted version 2.17.5 is working again now as well. Thanks everyone!
I tried it but I still have the same issue. you set 2.17.5 for n8n runners image too?
even when I try older versions, 2.14.2 for example, I get the same invalid token error and the wait node stuck in waiting
I have N8N_RUNNERS_ENABLED=true but I’m running in internal mode (default), so runners are child processes of the same container using the same image. Updating the main n8nio/n8n image to 2.17.5 was enough to resolve the wait node issue for me. If you’re running in external mode with a separate n8nio/runners container, that one needs to be on 2.17.5 as well.
thank you. but earlier I changed runners image to 2.17.5 too and still not working
Hi. I had that trouble, i tested with version 2.18.0 and it works!!! we have o wait that version to be estable.