Describe the problem/error/question
Crashing of n8n's cloud instance workflow.
My workflow has been running smoothly since last 3 months, but yesterday out of no where it fails 3 times and n8n automatically switches it off. There have be incidents where system had failed over 30 executions but never turned off . This got turned off after 3. Also I had retry 3 times on the nodes where it failed but still it crashed due to some memory space running out. In the documents, it says that n8n will restart the instance automatically but that also did not happen as I manually started it again after a a day today. Any precautions I can take for future?
What is the error message (if any)?
Execution stopped at this node
n8n may have run out of memory while running this execution. More context and tips on how to avoid this in the docs
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:
Hi @Aarush_Bisht
To prevent memory-related crashes, you should focus on reducing the “memory footprint” of your data as it moves through the workflow.
A. Implement Batching (The most important step) If you are processing a large list of items (e.g., 1,000+ rows from a database or API), do not pass them all to the next node at once.
- Use the “Split In Batches” node: Process items in smaller chunks (e.g., 50 or 100 at a time). This ensures that n8n only holds a small subset of data in active memory at any given moment.
B. Avoid “Heavy” Data in Memory
- Limit Fields: Use a Set node or Edit Fields node to remove unnecessary data early in the workflow. If an API returns 50 fields but you only need 3, delete the other 47 immediately.
- Binary Data Handling: If you are dealing with large files (PDFs, Images), avoid keeping multiple copies of the binary data in the workflow stream. Use the “Read/Write Binary File” nodes or external storage (like S3 or Google Drive) and pass only the file ID/URL between nodes.
C. Optimize Node Execution
- Avoid Large Loops: Deeply nested loops or recursive calls can quickly consume the stack and heap memory.
- Wait Nodes: If you are hitting an API in a loop, add a Wait node (even for 1 second). This not only prevents rate-limiting but can also give the Node.js garbage collector a window to clear out unused memory.
D. Monitoring and Alerts
- Error Workflow: Create a dedicated “Error Workflow” (via the Workflow Settings) that sends you a Slack or Email notification the moment a failure occurs. This allows you to intervene manually before the system hits the “Circuit Breaker” limit and shuts the workflow off.
It had been working fine for months but crashed/unpublished one day only after 3 different execution fails .( I have implemented 3 retries for a node per execution). The amount of data is also not much ( literally just 50-60 lines of employee data). Have implemented error handling too , I have done ‘always output data’ and then if error detected message me. Neat part is it did not followed that too. Neither tried retry , just got failed and unpublished .
50-60 line of data was for one employee.
and one of the 3 which failed was a js code node where i was itself trying to reduce the dimensions of data.
{
“nodes”: [
{
“parameters”: {
“jsCode”: “\nconst updates = $node[“Webhook”].json.body.data.fieldUpdatesIds.map(f => f.id);\n\nconst targetFields = [\n “work.site”,\n “work.department”,\n “work.siteId”,\n “work.customColumns.column_1732603686850”,\n “work.workChangeType”,\n “work.title”,\n “work.activeEffectiveDate”,\n “work.reportsTo”,\n “root.displayName”\n];\n\nconst check = updates.some(id => targetFields.includes(id));\n\nreturn [{ check}];\n”
},
“type”: “n8n-nodes-base.code”,
“typeVersion”: 2,
“position”: [
-3104,
496
],
“id”: “7e8b7768-aa58-4218-98bb-24008a7ea4ef”,
“name”: “Code in JavaScript1”
}
],
“connections”: {
“Code in JavaScript1”: {
“main”: [
]
}
},
“pinData”: {},
“meta”: {
“instanceId”: “0f39d8fdd402ddce20d0eb724526828e8c2d8679170e3a08fe6cd471c799fab6”
}
}
logs for particular 3 executions can not be checked as n8n says that logs are not saved due to execution fail. ( weird , as logs of fails are more important ) .
1 node failed which was just there to get auth token. no loop just one api hit. Third one (HTTP node) had some imageUrls in response but not images ( based on previous executions) . All three failed together in 3 different executions with same reason.
Could it be some fault on n8n’s server side?
Very unlikely.
Your code is logically simple and should not crash a server with 60 lines of data. However, there is a performance risk in how it accesses data:
const updates = $node["Webhook"].json.body.data.fieldUpdatesIds.map(f => f.id);
Using $node["NodeName"] forces n8n to keep the entire data object of that previous node in the active memory heap for the duration of the workflow. If your Webhook payload is large, and you have multiple nodes doing this, you are multiplying the memory usage.
Replace your current JS code with this version. It uses the modern syntax and adds a “safety check” to prevent the node from crashing if the data is missing (which would otherwise cause a TypeError):
// Use the modern $(...).item syntax for better memory management
const webhookData = $("Webhook").item.json.body?.data?.fieldUpdatesIds;
if (!Array.isArray(webhookData)) {
return [{ check: false, error: "No fieldUpdatesIds found" }];
}
const updates = webhookData.map(f => f.id);
const targetFields = [
"work.site",
"work.department",
"work.siteId",
"work.customColumns.column_1732603686850",
"work.workChangeType",
"work.title",
"work.activeEffectiveDate",
"work.reportsTo",
"root.displayName"
];
const check = updates.some(id => targetFields.includes(id));
return [{ check }];
To ensure you actually get logs when things go wrong:
- Go to Workflow Settings (the gear icon).
- Ensure “Save Failed Executions” is turned ON.
- Set “Save Successful Executions” to OFF (or “Only if error”). This frees up database resources and makes it easier to spot the “poison” executions.
Since you mentioned the HTTP node had imageUrls, check if any of those URLs are returning massive metadata or if the response body is unexpectedly large. Even if it’s not the image itself, a huge JSON response can spike memory.
I just checked for failing executions it was default save. The json data just had image URLs , and not more of sort. Also just looked at the data which all nodes are receiving from webhook( yes, that code node was processing that data ). It is basic slack event webhook receiving 20-30 lines of API request meta-data (in headers) and 10 lines of body and some other info in JSON .(Nothing seems wrong) . My problem is that if I anytime went on leave and this happens then, the system might be down for a while then.
Two possibility:
- Cumulative Leak: Over 3 months, small amounts of memory might not have been cleared properly. Eventually, the “baseline” memory usage became so high that even a tiny Slack webhook pushed it over the limit.
- Concurrency: If 5 or 10 Slack events hit your webhook at the exact same second, n8n spins up multiple parallel executions. Even if each one is small, 10 simultaneous processes can spike the RAM and trigger the crash.
Since you are worried about the system being down while you are on leave, you cannot rely on n8n to monitor itself (because if it crashes, the monitor crashes too). You need External Monitoring.
Use a free service like Better Stack, UptimeRobot, or Cronitor.
- Create a very simple second workflow in n8n:
Webhook Trigger →Respond to Webhook (200 OK).
- Set the external monitor to ping this URL every 5 or 10 minutes.
- If the monitor gets a 500 error or a timeout, it will send you an email/SMS immediately. You will know the instance is down before your main workflow misses critical data.
Looking at your settings screenshot, you have “Save successful production executions” set to “Save”.
- Change this to “Do not save”.
- Why? Every time a successful execution is saved, n8n has to hold that data in memory and write it to the disk. For a high-frequency Slack webhook, this creates constant “churn” in the memory. By only saving failures, you significantly reduce the load on the instance.
Since your data is objectively small and you’ve been running for 3 months, this could be an issue with the specific “node” (the physical server) your instance is hosted on.
- Send n8n cloud support or help@n8n.io the screenshot of the “Interrupted” execution.
- Tell them: “My workflow is processing very small Slack payloads, but I am seeing ‘Interrupted’ executions and the Circuit Breaker is unpublishing my flow. Can you check if my instance is experiencing memory pressure or if I should be moved to a different host?”
Can I do something to fix cumulative leaks? Like restarting the workflow or something? Switching off for successful iterations might not be option for me ( company’s instance , hence need to keep complete records atleast for past some days.) Concurrency can possibly be an issue as all 3 failed executions occured together ( but I have seen n8n handle 8-10, even more sometimes). External monitoring might not be needed as n8n themselves send a message to mail that they switched it off and we are informed. ( I meant that who takes office laptop on vacation 
)
Restarting the workflow itself will not clear a leak; the reset point is the running instance or worker. For this case, the sharper clue is that the three failures happened together, not that the Code node is heavy.
Check one window, no employee data needed: did the three Slack webhook executions start within the same few seconds, and were any other executions running at that moment? If yes, the next boundary is a small queue/serial gate before the employee-update path, so Slack is acknowledged quickly but only one update job is processed at a time. If they were spaced out, treat it as a Cloud/runtime incident and give support the three execution IDs plus the auto-disable timestamp.
might be problem of concurrency . is there a way to deal with these? like can we delay executions coming at same time by some time?
Yes, but do not put the delay after the heavy nodes. If three Slack events already started the full workflow, a Wait node just leaves three executions alive at the same time.
Keep the Slack intake tiny: receive the event, acknowledge it, and put only the event id/body needed for the employee update behind a one-at-a-time gate. Then process that second part on a cadence or queue. You can still keep execution records; the thing to reduce is parallel work in the employee-update branch, not record retention by itself.
I guess the event was already small as webhook data was not large (max 50-60 line json) and we need few fields from it ( what the code node was performing- dimensionality reduction of data ) . It is just that the request just came in parallel. I have seen https req getting MBs of data and still not crashing. Anyways , I will try to get this to n8n staff (if possible for me). Thanks for help, will try to implement these suggestions in future workflows.
