Hello,
I’m experiencing recurring “connection lost” / “offline” issues while using n8n Cloud through the web interface, and I would like to report the problem because it does not seem to be caused by my setup or internet connection.
My workflows are relatively simple:
-I do not have a large number of workflows
-The workflows are not especially long or complex
-Most of them are scheduled scraping/automation workflows
-The issue often happens around HTTP Request nodes
What happens is:
while a workflow is running, the interface suddenly shows “Offline” or loses connection sometimes the execution stops with messages related to memory or interrupted execution. Despite that, it is always after losing connection and however, if I execute the same workflows manually one by one, they usually complete successfully
I already redesigned my architecture to reduce load:
-Separated workflows instead of chaining many subworkflows together
-Added retries only on external API nodes
-Reduced execution complexity
-Staggered execution times between workflows
Even after these optimizations, I still occasionally experience random connection losses.
Since I am using n8n Cloud directly from the browser, I would like to know:
-Whether this is a known issue
-If there are stability limitations on the Starter plan
-Or if there is any recommended configuration to prevent these disconnections
Thank you for your help.
Describe the problem/error/question
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Share the output returned by the last node
Information on your n8n setup
- n8n version:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app):
- Operating system:
welcome to the n8n community @Raul_Martin_Acebes
I would first separate the browser “offline” message from the workflow execution itself, avoid running these workflows from the editor for long scraping jobs. Keep them active on Schedule Trigger, then check the execution history after they finish. If the browser disconnects but the execution continues, it is mostly a UI/session issue.
For the HTTP Request parts, I would add batching/pagination and smaller chunks instead of pulling too much data in one request. n8n’s docs mention using batching to reduce request size and add pauses between calls. Also store progress between steps, so a failed run can resume instead of starting from zero.
If executions are really stopping with memory/interrupted errors, I would capture the execution ID, timestamp, workflow name, and failing node, then compare whether it always happens on the same HTTP response size or endpoint.
Welcome to the community @Raul_Martin_Acebes! The setup you described is thoughtful and you’ve clearly already done a good job isolating the issue.
Building on what @tamy.santos said, I want to add a few more things specific to n8n Cloud scraping workflows:
1. n8n Cloud has execution timeout limits
On the Starter plan, workflows time out after 1 hour. If your scraping workflows hit multiple endpoints in loops, they can silently hit this limit and stop. The browser showing “offline” is often just the WebSocket session dropping, but the real culprit is the execution timeout. Check your execution history in Settings > Executions to see if they show “Error” with a timeout message.
2. Add a Wait node between HTTP Request calls
For scraping workflows, add a Wait node (set to 1-2 seconds) between batches of HTTP calls. This prevents memory spikes and reduces the chance of a single heavy request stalling the executor:
Loop > HTTP Request > Wait (1s) > next iteration
3. Use the “Continue on fail” option on HTTP Request nodes
With “Continue on fail” enabled + “Always Output Data” checked, a single failed request won’t kill the entire execution. You can filter failed items afterward.
4. Split large scraping jobs into smaller scheduled runs
Instead of one workflow scraping 1000 items, split into batches of 100-200 per run with a Schedule Trigger every 15 minutes. Much more stable on Cloud.
Can you share roughly how many HTTP requests are in a single workflow run and what plan you’re on? That’ll help narrow this down.
Thanks a lot for the suggestions.
I implemented batching with Loop Over Items + Wait nodes and the workflows are definitely more stable now. Since doing that, they no longer get unpublished automatically and most executions complete correctly even when some items fail.
However, I’m still occasionally seeing another issue that seems unrelated to workflow memory/load itself:
-
The editor suddenly shows “Offline” even if i am not executing any workflow.
-
I sometimes get random 502 errors like:
-
During that time I temporarily lose access to the workflows list/UI
-
This can also happen when no workflow is running at all
So at this point it feels more like a Cloud/UI/session/backend instability issue rather than the workflows exhausting memory.
Do you know the cause of this? I get this frequently during the day and I have good internet connection.
@Raul_Martin_Acebes
It looks more like a temporary failure between browser, n8n frontend, backend, and proxy/cloud, or some instability in the Cloud environment itself. I would try to capture the exact time of the problem, browser console/network errors and validate if this also happens in another browser or incognito window. If it still shows an error, I would send this information to support, because they can check the backend/proxy logs related to the 502 errors on their side.
How do I contact with support? I have been trying to solve the error and I could not.
Two separate things are happening here, and it’s worth splitting them because one of them probably isn’t a real problem.
The “Offline” banner in the editor is just your browser losing its live connection to n8n Cloud — the WebSocket that streams execution progress to the UI. It doesn’t stop the run. Scheduled executions run server-side whether or not your tab is connected, so a lot of the “it went offline” noise you can mostly ignore. The part that actually matters is the memory / interrupted-execution errors.
That smells like hitting the memory ceiling, which on the Starter plan is pretty low. Scraping is the classic trigger: an HTTP Request pulling a full HTML page or a big JSON response holds all of it in memory, and if that gets carried through several downstream nodes — or a couple of scheduled runs overlap — you blow the cap and the execution gets killed. It also explains why running them manually one at a time works: no overlap, low peak memory.
What I’d try, in order:
- Right after each HTTP Request, drop a Set/Edit Fields (or a small Code node) that keeps only the fields you actually need and discards the raw response. Dragging the full-page body through the whole workflow is usually what eats the memory.
- Process in batches — Loop Over Items / Split in Batches — instead of pulling and holding everything at once. Keeps peak memory flat.
- Make sure two scheduled runs can’t overlap. Staggering helps, but if a run takes longer than the gap to the next trigger, they stack. Widen the intervals.
If you do all that and still hit walls, then it’s genuinely the plan — Pro gives more RAM headroom. But I’d squeeze the payload down first; scraping flows almost always shrink a lot once you stop carrying the raw response around.