Memory ran out of issue

Questions
1

Hello n8n Community,

I am facing a serious out-of-memory issue on my n8n Cloud instance after the recent n8n security update.

My workflows were working completely fine until 25 June and had been running reliably for the past 7 months. I did not make any workflow, node, credential, configuration, or environment changes during the past week.

After the recent n8n security version update, multiple production workflows started failing during execution. When these workflows run, the instance becomes unstable or unresponsive, automations stop running, and the instance eventually runs out of memory.

I have already tried deleting saved executions, reducing execution history, and removing Wait nodes to reduce memory usage, but the issue still continues. Even after deleting executions, when the workflows run again, the instance still goes out of memory or crashes.

The same issue also happened in May after an n8n Cloud update. At that time, my workflows had also been stable for several months without any changes from my side, but after the update the instance started crashing with out-of-memory errors. The issue was eventually resolved after n8n updated the instance. Now, after the latest update, I am facing the same type of problem again.

This started only after the recent update, so I want to understand whether there was any recent change in n8n Cloud related to memory handling, execution behavior, child executions, workflow concurrency, or node behavior.

I would appreciate guidance from the n8n team or community on how to debug this and identify what is causing the memory spike.

I would also like to know if anyone else is facing the same issue after the recent update, or if this is only happening on my instance.

Output returned by the last node

The workflows fail before completing successfully. The execution status shows Error, and the main issue is out-of-memory behavior at the instance level.

In some cases, the executions fail very quickly, for example within milliseconds. In other cases, they run for several seconds before failing.

The instance also becomes unstable or unresponsive when the workflows run.

Information on my n8n setup

n8n version: n8n Cloud latest updated version
Database: n8n Cloud managed database
n8n EXECUTIONS_PROCESS setting: n8n Cloud managed / not directly configured by me
Running n8n via: n8n Cloud
Operating system: n8n Cloud managed / not applicable

Additional notes

The workflows were stable before the recent update. This issue started after the update, without any changes from my side.

I would like to know:

  1. Was there any recent n8n update that changed memory usage, execution handling, workflow concurrency, or node behavior?

  2. Is there any workaround, patch, rollback option, or recommended setting to stabilize the instance?

  3. Since the same issue happened in May after an n8n update and was resolved from the n8n side, can the team please check whether this is a similar instance-level or version-related issue?

2

@Asher_TMT a few people have hit this same post-update OOM on Cloud, so it points to a memory regression in the version you got auto-updated to, not anything you changed. which version did Cloud move you from and to around the 25th, that pins it. mechanism wise, n8n holds every items data in memory for the whole execution, so a build that carries more per item tips workflows that were sized fine right over. since trimming saved history didnt help, your lever is in-run memory not stored history, drop big fields with a Set node between the heavy nodes and split the heaviest steps into sub-workflows so each gets its own memory scope.

3

This pattern is worth taking seriously: stable for 7 months, no changes on your side, breaks right after a platform update, and the exact same thing happened in May and was resolved when n8n updated your instance. That correlation points much more at an instance/version-level regression than at your workflows. A few thoughts, split into “what only n8n can do” and “what you can do to narrow it down.”

Escalate it directly — this is the real fix path. Because you’re on n8n Cloud, the things that actually resolve instance-level memory (a patch, a rollback, or bumping the instance) are on n8n’s side, not yours — exactly like May. Open a support ticket and explicitly reference the May incident (same symptom, resolved by n8n updating the instance), plus the date this started (25 June) and the version before/after. That framing tends to get it routed as a regression rather than a config question.

Meanwhile, narrow down the culprit — this keeps you running and gives support a faster fix:

  • Find the offending workflow. In Executions, line up the crash timestamps against which workflow was running. A memory spike almost always traces back to one or two workflows, not all of them.
  • Usual memory culprits (an update can shift node behavior just enough to push a previously-fine workflow over the edge): large payloads held in memory (big HTTP responses, binary files/images/PDFs carried through many nodes), loops / SplitInBatches that accumulate all items instead of processing in chunks, and sub-workflow (“Execute Workflow”) child executions multiplying under concurrency.
  • Isolate by deactivation. Temporarily turn off the heaviest / most frequent workflows one at a time and watch when the instance goes stable — that pinpoints the cause fast.
  • One lever people miss: beyond global execution history, check each heavy workflow’s own settings and set “Save execution progress” to off and “Save successful executions” to off. Saving progress writes every node’s data and is a real memory cost on big-payload workflows. You already trimmed global history, but this per-workflow setting is separate.
  • For big-data workflows, paginate / batch so you never hold the full dataset in memory at once, and avoid passing binary through more nodes than necessary.

To speed up the ticket, hand them: the exact version before/after, the start date, the May ticket reference, the specific workflow + node, a couple of crashed execution IDs, and whether it’s tied to concurrent runs. That’s usually enough for them to reproduce.

Given the May precedent, my honest read is this is most likely something n8n needs to patch on their end — but the steps above should keep you stable and make the fix faster either way.

4

The memory-regression angle sounds plausible, especially if nothing changed in your workflows and the failures started right after the Cloud update. The immediate technical path is to reduce in-execution memory: drop large fields as early as possible, split heavy branches into sub-workflows, avoid carrying full payloads through later nodes, and isolate the workflow that spikes memory first.

For production workflows, I would also handle this as an incident, not just a debugging task:

  1. List which workflows are failing and which clients/processes they affect.
  2. Record when the issue started and which n8n version changed.
  3. Add a temporary check that confirms the critical workflows are completing.
  4. Document the mitigation you applied, such as field stripping or sub-workflow splitting.
  5. Decide whether the client/stakeholder needs a status update.

The operational risk is that multiple workflows fail silently while everyone focuses on the root cause. Keep a short issue log until the platform is stable again.