Cloud: executions stuck in "Queued / Starting soon" and OOM crashes

Questions
,
1

Describe the problem/error/question

Two problems on the same Cloud instance. They may well be related.

Issue A - executions stuck in the queue since 2026-07-01

Several executions entered the concurrency queue on 2026-07-01 at 00:52:48-00:52:51 CEST and have never left it. They never transitioned to Running. I cannot cancel or stop them from the UI, and I cannot force them to start. The executions overview reports no active executions while these entries sit there as “Queued / Starting soon”.

This has now been the case for over a month.

Example stuck execution: 698563

Issue B - OOM crashes on 2026-08-01

On 2026-08-01 at around 00:52 CEST, a single third-party system delivered approximately 70 webhook calls within 30 seconds to workflow IJ2lzInmEthm4e22. That is 2.33 requests per second. A large number of executions then failed with an out-of-memory error, i.e. the instance process was OOM-killed and restarted, repeatedly.

Example failed execution: 778602

What is the error message (if any)?

For Issue B:

Execution stopped at this node
n8n may have run out of memory while running this execution.

Timestamp in the error detail: 1.8.2026, 00:54:07
n8n version shown in the error detail: 2.32.7 (Cloud)

For Issue A there is no error message at all. The executions simply never start.

Information on your n8n setup

  • n8n version: 2.32.7
  • Running n8n via: n8n Cloud
  • Instance: - will not share here -
  • Operating system: n8n Cloud

Additional context

The webhook node is set to “Respond Immediately”, so the HTTP response does not extend execution time. No manual executions were running. The monthly execution quota was not exhausted.

2.33 requests per second is a trivial rate. At any plan’s concurrency limit, a burst of this size should produce nothing worse than a short backlog that drains within roughly a minute - which is exactly what the concurrency queue is documented to do: executions beyond the limit queue up and are processed in FIFO order as capacity frees up. Instead it produced process-level OOM crashes.

Issue A is not specific to my instance. It matches GitHub issues #23675 and #24594 and several community reports, in which n8n support confirmed this class of problem is not user-fixable and has to be escalated internally.

What I need

  1. The orphaned queued executions from 1 July cleared. The documentation states that queued executions cannot be retried and that cancelling or deleting one also removes it from the queue. Neither works here, so this needs action on the n8n side. I am not going to work around it via the public API on a production instance.

  2. A root cause explanation for Issue A. Is the queue recovery path a known defect? Is a fix shipped or planned, and in which version? An execution that cannot be started, stopped or removed by the account owner for a month is not an acceptable state for a managed product.

  3. For Issue B: there is evidently no per-execution memory isolation on Cloud, so one memory-heavy execution can OOM the shared process and take down every other execution running in it. A managed plan that advertises a concurrency limit has to be able to actually run that many concurrent executions without the process dying. This is a dimensioning and isolation problem on the platform side and it needs to be fixed there.

2

Hey @Brandwork_JB, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Wilson_Eugenio, @JavierOrjNeq, @Anshul_Namdev - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @Brandwork_JB

Since you are on n8n Cloud​, you cannot perform the infrastructure fixes yourself. You must provide the following specific technical demands to n8n Support to move this beyond a first-tier response:

  1. For Issue A (The Cleanup):

    • Request a Manual Database Cleanup​. Specifically, ask them to run a query on your instance to set status = 'failed' for all executions in the queued state created on 2026-07-01.
    • Reference the GitHub issues you mentioned (#23675, #24594) to signal that you know this is a backend state-machine failure.

  2. For Issue B (The Stability):

    • Immediate Mitigation: If the workflow IJ2lzInmEthm4e22 processes large amounts of data, implement Batching​. Instead of processing the webhook payload immediately, push the data to a Queue (like RabbitMQ or a simple database table) and use a separate “Worker” workflow that processes items one by one or in small batches.
    • Platform Demand: Ask n8n Cloud support to review the Memory Limit of your specific container. If you are on a plan with a high concurrency limit but low RAM, the plan is fundamentally misconfigured for the advertised concurrency.
4

Hi @kjooleng ,

Thank you for your advice! I will follow your instructions.

For part 2 of your answer: My workflow which caused the OOM here does not process large amounts of data. Its simply a webhook endpoint which loads a dataset and updates the data based on the webhook payload. It also normally just takes about 1.5 seconds for completion.

Do you have experiences with similar cases, because you recomend the usage of a queue system? If so, I would appreciate a recommendation what system to use here and which provider.

Thanks!

5

@Brandwork_JB

I recommended a queue because, in a shared-process architecture (like n8n), the only way to guarantee 100% stability against bursts is to decouple Ingestion (Webhook) from Processing (Workflow).

However, given your workflow is lightweight, you should not have to implement a complex external queue just to handle 2 requests per second. That is a failure of the platform’s resource allocation.

6

Hi @Brandwork_JB
The concurrency limit is not memory aware, so a burst that sits inside it can still blow the heap. Cloud RAM is fixed per plan: 320MiB on Trial and Starter, 640MiB on Pro-1, 1280MiB on Pro-2, 4096MiB on Enterprise, and n8n itself averages around 180MiB of that before a single execution runs. 70 parallel runs of a workflow that loads a dataset hold 70 separate copies of that dataset in the same heap, so a 1.5 second workflow at 2.33 requests per second can still OOM the process.
Cut what each run holds, not what it does: query only the records the webhook payload actually touches instead of loading the dataset and narrowing it inside n8n. That is the one lever you have on Cloud without changing plan.

On the July entries, the OOM restarts on 1 August already exercised the startup recovery path, which resumes queued executions up to the concurrency limit and re-enqueues the rest. Those rows still did not move across repeated restarts, so they are in a state that recovery does not pick up. Worth stating in your ticket, it rules out a restart fixing it.
More on what each plan actually gives you for concurrency and queuing:

7

Keep the stuck queue and the OOM as separate incidents until support shows they share a cause. The month-old queued rows are already outside what you can repair from a Cloud workflow. Cloud docs say canceling or deleting a queued execution removes it, so rows that survive both actions need backend cleanup.

For the OOM, elapsed time is a weak proxy for memory. A 1.5 second workflow can still materialize a large dataset per execution, and 70 overlapping runs multiply that working set. Respond Immediately closes the webhook response. The remaining nodes continue to run.

Before adding RabbitMQ or another provider, make a minimal copy that accepts the same webhook but replaces the dataset load and update with a No Operation node. Send the same burst to that copy in a controlled test. If the minimal copy stays healthy, inspect item counts and field sizes around the dataset load in the real workflow. If it also OOMs, give Cloud support the execution IDs with their timestamps because you have isolated the failure from the workload.

A queue can smooth bursts, but it would be a mitigation. It would not clear orphaned executions or explain why the Cloud process died.

n8n Cloud concurrency reference: Understand concurrency | Deploy | n8n Docs

8

The 70-webhooks-in-30-seconds case won’t be solved by concurrency limits, because the memory is already spent by the time the limiter sees the execution — the body is parsed and resident before anything queues. The split that holds up: one workflow whose only job is to write the raw body somewhere durable and return 200 immediately, and a second scheduled or queue-triggered workflow that drains it at a rate you control.

On the stuck July executions, ask Support for the concurrency slot count on that instance, not just a database cleanup. Executions that sit in Queued for a month usually mean slots were leaked, and a cleanup that doesn’t reset those puts you straight back where you started.

9

Buffering the payload and draining it later is a sensible containment step. I would keep the two mechanism claims as hypotheses, though. The public symptoms do not establish that n8n retains the full body before its Cloud concurrency gate, or that a leaked slot caused the July rows.

For Support, ask for the queue records around the affected execution IDs and the instance’s current concurrency state. If capacity is available while those rows remain queued, orphaned queue state becomes likely. If the counter shows capacity consumed with no matching running executions, a leaked counter becomes much stronger.

That distinction matters. A buffer can reduce future peak memory, but it will not repair stale backend state.