We’re having a lot of performance issues for the last month. I’ve seen that the version 1.105 was causing a lot of troubles, but I’m wondering if it’s sill the case?
Current issues:
503 errors, a lot of crash
Scheduled workflows not triggered
Workflows are super time consuming (a simple database request taking 2 seconds on my computer takes nearly 1 min on n8n when not timedout)
We’ve already tried to improve our config (self-hosted):
4vCPU
8 Gb RAM
I’m pretty convinced it’s not due to the config (clearly overkill, only reaching 30% on spikes).
We run around 100,000 executions/months.
We’re considering downgrading to v1.104
Any guess/similarities on your side?
Thanks a lot!
Information on your n8n setup
n8n version: v1.111.1
Database (default: SQLite): Postgres
n8n EXECUTIONS_PROCESS setting (default: own, main): main
Running n8n via (Docker, npm, n8n cloud, desktop app): docker
Some users report improvement in AI Agent response times with this env variable:
N8N_RUNNERS_ENABLED=false
Apart from that, I would definitely downgrade and log any details you might have gathered in a Github issue to help them investigate. Hope this helps at least a little.
Deprecation Warning: Running n8n without task runners is deprecated. You will see warnings in your logs recommending you to enable task runners, as they will be turned on by default in a future version of n8n. This means that, eventually, you may be forced to use task runners as n8n evolves Task runner environment variables | n8n Docs.
Workflow Execution Model: Without task runners, all workflow executions (including Code node executions) happen in the main n8n process. This is the legacy behavior. Enabling task runners offloads Code node execution to separate processes, which can improve isolation and stability for complex or resource-intensive workflows.
Potential for Fewer Issues (Currently): Some users have reported that enabling task runners (N8N_RUNNERS_ENABLED=true) caused issues such as workflows crashing, Code nodes not working, or performance problems. Disabling task runners resolved these issues for them, allowing workflows to run as before N8N_RUNNERS_ENABLED crash my WF, Code node doesnt work after update 1.84.1.
No Need for Additional Configuration: If you are not using task runners, you do not need to set up the additional environment variables required for their configuration. This can simplify your setup, especially if you are running everything in a single container Task runner and environment variables: a minimum setup set.
Summary:
Disabling N8N_RUNNERS_ENABLED keeps n8n in its legacy execution mode, which may currently be more stable for some users, but it is deprecated and will not be supported in the future. You will also miss out on the isolation and scalability benefits that task runners provide. If you encounter issues with task runners, disabling them can be a temporary workaround, but you should plan to adapt your setup for future n8n releases.
Btw, let me know if this helps at least a little and if you don’t have any follow up questions feel free to mark my first reply as Solution, if it helped you move forward
I thought my first message and the title was pretty clear, sorry!
Current version: v1.111.1
I said that I saw ppl complaining about v1.105 on the forum. So we’ve tried yesterday downgrading to V1.104, but it wasn’t retro-compatible so we had to keep v1.111.1 for now
We were in contact with n8n team, and it apparently solved most of the issue, as @krisn0x suggested.
Thank you for the information. After reviewing, I noticed you are using Env Var: N8N_RUNNERS_ENABLED Value: true, which is not recommended for production.
Also, in your document, you mentioned “Workers,” but I do not see a declaration of the Execution mode for the n8n instance EXECUTIONS_MODE , to use “Workers” you need to be using Queue mode and have deployed n8n worker instances together with your n8n main instance, and also deploy Redis as the queue manager.
Besides what I am mentioning above, the current issue points to a resource constraint.
