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.
Have you checked your scheduler logs around the point where the waiting nodes got stuck? Sometimes it’s a scheduler state memory leak where the waiting jobs get removed from the in-memory queue but aren’t properly cleaned up from persistence. If it’s consistently 2.16+, might be worth checking the release notes for scheduler changes. Quick test: do new waiting nodes work properly or is everything stuck?
@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.