After updating our self-hosted n8n instance to version 1.105.2, one of our workflows — likely the largest one we run — started taking significantly longer to execute.
Before the update, the workflow completed in 0–3 seconds. After the update, it consistently takes 60–63 seconds (sometimes slightly more). Other workflows continue to run as expected.
There are no obvious differences between this workflow and the others, apart from its size — it uses the same node types and connects to similar databases.
We would appreciate any help understanding:
What might have changed in the update to cause this?
Is there a way to trace execution time per node to identify where the slowdown occurs?
Is this a known issue with large workflows in recent versions?
Is it fixable, or should we consider restructuring the workflow logic?
We have 615 nodes in this workflow. Any suggestions on debugging or optimizing it would be greatly appreciated!
What is the error message (if any)?
There are no error messages — the workflow completes successfully, but takes significantly longer than before.
n8n version: 1.105.2
Database (default: SQLite): Postgres
n8n EXECUTIONS_PROCESS setting (default: own, main): own
Hi @w1nway, Thanks for reporting the issue. Could you please share more details about the workflow? Does it have any “Respond to Webhook” nodes? Is downgrading to 1.104 an option? I just want to make sure that updating to 1.105 is definitely the reason, as we are currently investigating similar issues.
Difficult to say where is the problem. For me it seems to be when "“Always output data” is active and when this node uses informations collected in an another node that is not just behind it.
In my case, no “Respond to Webhook” node. You teammate @tomi is on it too !
When downgrading to 1.104.x, the workflow turns perfectly right
first time here but I have been using n8n heavily in the last 6 months. my observation is the same, I have a very complicated workflow with maybe close to 50 nodes or more (never really counted it), it didn’t matter whether I run it as a test or trigger it by a production webhook. what used to take 50 sec now takes 30 min+.
as zlebandit has mentioned I definitely have LOADs of
“Always output data” is active and when this node uses informations collected in an another node that is not just behind it.”
type of set up. - downgrading cures the problem. One major observable change is that the new version now has a new symbol on the top right of the node when you have special setting like always output data.
It feels like the UI also loads slower and much more often getting stuck. Though this was already an issue for me as my workflow was already exceedingly complex to handle complicated logic (I didn’t feel it was appropriate to send data to various workflow during development).
but perhaps I need to start looking at modularising it once I have it all working..
lastly, my workflow will “error” out saying that it executed for too long too many request that sort of thing (too late here for me to replicate and get the error message) and then if I just leave it and walk away, it will eventually be a successful execution, hmm, curious behaviour.
in any case this has become a much longer rant than what I initially intended to say.
hopefully the next version will have this issue fixed as it’s quite useful to display these settings like ‘continue on error’, ‘always output data’ etc. much easier to visualise.
for now, I will need to turn my auto update off…
btw @w1nway is it some crazy optimisation you have done for a workflow with 600+ nodes to only take 3 seconds? or is it just my lack of best practices that it’ll take a min for a workflow with much less (I image you’d have loops and various LLM agents nested in there as well?)
After upgraded last friday to [email protected] all are problems, i cannot access to Workflows console, and many workflows not working,
any newest version has the same problem.
I never had problems before.
Sadly because i am paying in cloud pro 50k, i cannot select any older version (if i were self hosted with docker i could install any older version), and since friday i have problems in my n8n cloud corporative, with no solutions.
Here to confirm that I have also experienced this and have had to revert from backups as the new versions are absolutely tanking performance and breaking processes as executions are timing out.
The last stable version that we can connect to (one version had a connection port mapping issue) was 1.104.2.
I’m using Cloudron and all subsequent editions of n8n are a problem. I’ve seen multiple updates since and so I keep going through the process of updating, but get punished each time so turned off updates and now have to trial installations after hours each night to see if these issues have been fixed.
If you don’t have error messages / timeout redundancy built into your process these executions are failing silently which is a massive problem for users because they won’t even know their processes are failing.
We’re not doing anything too complex with our processes - but they all contain loops, they all contain Microsoft nodes such as Outlook and Teams and some have webhooks.