n8n · Help

n8n Cloud executions stuck on Queued or Starting soon?

Executions remain queued or the instance restarts? Inspect backlog, active runs and workload before replaying incoming events.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

Queued or Starting soon describes waiting work rather than a confirmed cause. n8n Cloud limits concurrent production executions; a manual editor run does not test that production queue. First record the oldest waiting IDs, active executions and corresponding business references. Check destination state and, if needed, send a small test through a published production trigger before creating replays that could compete with queued work starting later.

Source basis: Q1 · Q2

Applies to
The report concerns n8n Cloud 2.32.7 with backlog and memory crashes. Assess capacity, historical entries and current workload separately; this is not a Cloud database repair procedure.
How to verify the result
Accepted source events reconcile with completed destination results; the backlog progresses without manual replays producing additional effects for work that was already waiting.
Your first check

Which queued events have already produced a destination result?

New n8n Cloud executions remain Queued or Starting soon. Some do not progress even after a long wait. Restarts or out-of-memory errors may appear at the same time. Before sending additional copies of events, distinguish waiting work from processing that has already begun.

Assess backlog and memory failures separately

An original report for n8n Cloud 2.32.7 describes long-lived queued executions and crashes during a burst of webhook traffic. It establishes that reported combination, not a universal cause for every backlog. Q1 n8n documents a Cloud limit on concurrent production executions and a queue for waiting work. Queued executions cannot simply be retried like failed runs. Q2

A queue is therefore a state, not a diagnosis. Determine from the timeline whether capacity is occupied, an execution is stalled or another platform problem is involved.

Investigate the backlog systematically

  1. Record the inventory. Capture the oldest queued execution IDs, workflows, arrival times and number of new entries. Compare them with executions actually running. Age alone does not explain why an entry is waiting.
  2. Preserve business references. Associate each waiting operation with its source event ID. Where state is uncertain, check whether the destination already processed it. A queued execution that later starts must not compete with a manual replay.
  3. Describe the workload. Compare quiet periods with the incident window: arrival rate, payload sizes, binary files, output volume and execution duration. One large payload can behave differently from many small jobs.
  4. Use a controlled example. Send one small, harmless record through the published production trigger of a separate workflow. A manual editor run does not test the same production queue. If that also fails to start despite apparently available capacity, record it as evidence for support. It does not justify manipulating an inaccessible Cloud database.
  5. Escalate with evidence. Provide instance, plan, version, execution IDs, time window and observed restarts. If cancellation does not take effect, capture the original state rather than repeatedly generating new cancellations or executions.

Apply targeted load reduction

Once workload pressure is established, controlled intake, smaller processing units or reduced data volume may help. More capacity may also be appropriate, but it does not reconcile work already queued. Deleting an entry can discard required business processing, so record a decision for each affected event first.

After recovery, compare accepted source events with completed destination results. A shorter queue is useful operational evidence; matching the expected business work establishes whether recovery is complete.

Frequently asked questions

Can I send all the events again?

Only after establishing what already happened to them. Queued or newly started copies may still complete successfully later.

Does an OOM error explain every old queued entry?

No. Establish the timeline and affected executions separately. An old stalled entry and a current workload spike can be different problems.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0167 with KAN KAI WORKS.

Support with this issue

We investigate n8n using your error message, versions and a narrowly scoped example.

Describe your case →Related service: AI & automation

Sources

Sources checked on 5 November 2026. Individual reports do not establish general prevalence.