Describe the problem/error/question
Is queue mode became default in v2? We have workflows that runs more than a couple of minutes to half an hour which we don’t encounter when we are in v1. All of our workflows were running in maximum of 2 mins. But now even the simple workflows consisting of 5-10 nodes that was running for few seconds, it’s now running 2-10 mins.
I know we can increase workers but I wonder if it’s best to turn the queue mode for the mean time?
What is the error message (if any)?
This execution failed to be processed too many times and will no longer retry. To allow this execution to complete, please break down your workflow or scale up your workers or adjust your worker settings.
Information on your n8n setup
- n8n version: 2.13.2
- Database (default: SQLite): postgres
- Running n8n via Docker
- Operating system: Linux / Kubernetes
queue mode isnt default in v2 anyway. sounds like a worker throughput issue — the “failed to process too many times” error means your worker queue is backing up. try disabling queue mode if youre not distributed, scaling up your workers, or check if docker resource limits are squeezing you. whats your setup, running docker or k8s?
1 Like
Hi @jmozzart this can happen due to insufficient hardware, also you maybe can try increasing the limit with QUEUE_WORKER_LOCK_DURATION maybe 120000ms and also make sure this is enabled N8N_RUNNERS_ENABLED=true and it is actually on the nodes, if you are using even 3 huge data nodes they would take time, so consider that also.
1 Like
We haven’t run into this issue before, and the instance is handling the same amount executions as usual. We haven’t added any additional workload recently.
Dann deutet es wahrscheinlich auf einen Hardware-Limit hin, der nach dem Update aktiver wird — Docker Resource-Limits oder K8s CPU/Memory Requests neu konfiguriert? Check deine Environment-Variablen nach dem Update und vergleich deine Worker-Config mit v1. Kann auch ein Resource-Bottleneck bei Postgres sein wenn viel I/O passiert.
@jmozzart have you tried rolling back to the version which was working perfectly?
Running n8n in queue mode on Kubernetes - I’ve hit this exact pattern before. A few things to check:
1. Task Runner config (new in v2)
v2 introduced task runners. Make sure N8N_RUNNERS_ENABLED=true is set on your worker pods. Without it, tasks can queue up waiting for a runner that’s not properly initialized.
2. Worker concurrency
Check your EXECUTIONS_PROCESS env var. In queue mode, the default concurrency per worker is often lower than you’d expect. Add this to your worker deployment:
QUEUE_WORKER_TIMEOUT=300
N8N_CONCURRENCY_PRODUCTION_LIMIT=20
3. Redis connection pool
If you’re on Kubernetes with multiple worker replicas, Redis connection exhaustion can cause jobs to sit in the queue. Check your Redis max connections vs number of worker pods × concurrency.
4. The real root cause for your case
You mentioned simple 5-10 node workflows now taking 2-10 mins - this points to jobs sitting in the queue waiting for an available worker, not the execution itself being slow. The job runs fast once it starts, but waits too long.
Quick diagnosis: check your Redis queue length with MONITOR while triggering a workflow. If you see the job sitting there for minutes before being picked up, it’s a worker capacity issue not a workflow issue.
Don’t roll back yet - fix the runner config first.
1 Like
Brilliant diagnosis, @nguyenthieutoan. The task runner config and Redis queue length are the ones most people miss after upgrading to v2. That monitoring trick with Redis MONITOR will immediately show if jobs are sitting in queue waiting vs actually executing. Good call on not rolling back—fixing the config first will likely solve it.
@jmozzart
One thing that hasn’t really been called out yet is that queue mode did not become the default in v2 by itself, so I’d first confirm whether you are actually running with EXECUTIONS_MODE=queue and how your main, worker, and Redis pods are currently configured. I’d also be careful not to over-focus on task runners unless these workflows actually use Code or Python nodes. For simple 5-10 node workflows, the more interesting signal to me is the retry message, because that suggests the executions are not just slow, but getting reprocessed or failing to be picked up cleanly. So before turning queue mode off, I’d check worker concurrency, retry behavior, Redis health, and whether anything changed around execution data retention or Postgres load after the upgrade.
Great point — focusing on worker capacity, Redis queue health, and execution retries first is definitely the right order. Task runner config comes later if needed, but the basics often solve it.