For a few months now the editor on my n8n Cloud instance has been almost unusable, and it’s the same in every browser (Safari, Chrome, Firefox, Edge) and on different machines.
What happens:
- Opening the Workflows list, Executions, or a canvas often gives a blank white page for 30–60 s. Sometimes it loads, sometimes it just stays blank with the tab spinning forever.
- On the canvas I get “Connection lost / Reconnecting” over and over. Half the time I can’t even start a manual “Execute workflow” because the connection drops mid-way.
- The tab eventually freezes. Closing it and opening a new one works for a bit, then it starts again.
Meanwhile the instance itself is fine: /healthz returns 200 (slow, 1–5 s), and all my scheduled workflows run and deliver normally. So it feels like a frontend / push connection issue, not a workflow issue.
My workflows are big (368, 104 and 102 nodes). The 368-node one is the worst on the canvas, but the smaller ones and even the plain list pages are affected too, so it’s not just canvas rendering. It has survived many version updates.
I’ve emailed help@n8n.io as well. Posting here in case anyone has seen this or knows a workaround — resource limits, push settings, splitting large workflows?
No error message, just the banner and blank pages. Screenshots attached.
Debug info: n8n 2.40.5, cloud, Node 26.7.0, sqlite, executionMode regular, concurrency 5. Client: Safari 27 on macOS (same on Chrome/Firefox/Edge).
A slow /healthz on Cloud usually means the instance is short on memory or its SQLite database is overloaded, not that the browser has a problem. The editor’s push connection is the first thing to drop when that happens. With workflows this big, the usual culprit is saved execution data: every run of the 368-node workflow writes a large record, and the Executions list and canvas both read from that same database.
In each big workflow, open Settings and set:
- “Save execution progress” to Do not save. This one writes to the DB after every node, which is brutal on SQLite.
- “Save successful production executions” to Do not save.
- “Save manual executions” to off.
Also check whether any node passes binary data or huge JSON through dozens of nodes. Trimming that with an Edit Fields (Set) node early on cuts memory a lot.
One question: how many executions do you have stored right now? If it’s tens of thousands, that alone explains the blank Executions page.
Hi @angin2209, /healthz returning 200 only means the instance is reachable, it doesn’t check the database.
Before splitting those workflows, open Chrome DevTools > Network, enable Preserve log, then reload the Workflows list with Fetch/XHR selected. Does the request fetching the workflows also take 30–60 seconds, or does it finish successfully while the page stays blank?
Click that request and share its status and Timing tab, without headers or response data. That will help separate a slow response from the editor failing to display it. Add the same details and the timestamp to your existing support ticket so they can check the instance at that time.
@angin2209 Top of the day to you here is the ultra-short checklist to get you n8n editor working again:
Stop Data Bloat : Open your 368-node workflow , go to settings (gear-icon), and change the save execution progress to Do not save . This stops n8n from writing database logs for all 368 steps . See the Executions | Deploy | n8n Docs.
Split the Big workflow : Break that 368-node monster into smaller , modular peices using the sub-workflow node. it saves massive amount of browser and server memory . follow the Break workflows into smaller parts | Build | n8n Docs
Filter Payloads Early : use an Edit fields (set) node near the start of you workflow to strip out heavy , unused data attributes so they don’t drag through hundreds of nodes . Read the Fix memory issues | Deploy | n8n Docs
Handle Files Better : If your workflow processes large images or PDF,S ensure you aren’t storing them in server RAM unneccessary . Check the Handle binary data | Deploy | n8n Docs.
If the UI stays blank after changing the execution settings, share your chrome devtools Network tab showing the exact loading time of your rest/workflows request so support can clear any stuck database locks
Update on this issue:
Support initially suggested that the issue might be caused by large workflow sizes (e.g., node count overloading the browser tab and dropping the editor connection). However, after further testing, the evidence strongly points to server-side/cloud infrastructure instability or WebSocket/proxy handling issues, rather than workflow complexity:
-
Slow loads before opening any workflow: The editor UI and dashboard (Workflows list, Executions view) often hang with a blank page for 30–60 seconds upon first visit—well before any workflow canvas or node graph is loaded.
-
Persistent “Offline” state even on empty workflows: When the connection drops, closing the tab, starting a fresh session, and opening/importing an entirely empty workflow still results in the same immediate “Offline / Connection lost” banner.
-
Historical baseline: Over the past year, I have built and operated equally large or heavier workflows on this setup without encountering persistent disconnects. This behavior only became frequent and disruptive in recent months, indicating recent cloud proxy timeouts, WebSocket drops, or frontend connection regressions rather than client-side rendering bottlenecks.
Has anyone else on n8n Cloud experienced recurrent “Connection lost” / canvas freezing issues regardless of workflow size? Hoping the n8n infrastructure team can look into instance-level WebSocket routing and backend stability for this.
Hi @angin2209
I looked at your instance’s server side over the past week. The backend answered quickly the whole time. Requests for the workflows list, the executions list and your largest workflow all came back well under 2 seconds. Memory stayed comfortably below its limit and there were no restarts apart from the version updates. Your /healthz checks also answered in a few milliseconds once they reached n8n, so the 1–5 seconds you measure is added somewhere between your browser and our servers.
That leaves two places to look. One being the network path from your location to n8n Cloud and the other the browser tab itself.
You mentioned the tab eventually freezing and a new tab working for a bit before it starts again. That points at the browser, so I’d start there.
The next time the editor goes blank these three things would help narrow it down:
- A HAR file of the page load. Open DevTools, go to the Network tab, enable Preserve log, reload, then use Export HAR. It shows whether the time is spent waiting on the network or inside the browser.
- If you can reproduce it in Chrome, the tab’s memory and CPU at that moment. In Chrome, open the menu (⋮) > More tools > Task manager.
- The same page loaded from a different network for example a mobile hotspot.
Please send these to your existing support ticket. A HAR file can contain session data, so it shouldn’t go on the forum.