Workflow keeps crashing due volume - do I need to upgrade? Would that work?

[Kayla_Campos]

Describe the problem/error/question

I’m running a workflow on an n8n cloud account and the workflow keeps crashing and then automatically being turned off by n8n. it seems like it is due to the sheer volume of executions as none of the nodes have any errors and when I retry the executions one by one they are successful.

I’ve tightened the retry settings on the nodes (down from 3 tries/2000ms wait) to reduce how long each execution holds a concurrency slot, and the Pro plan is capped at 20 concurrent executions. I was looking into upgrading as I thought that could be a solution but it doesn’t seem like bumping to the 50k execution tier actually raises the concurrency limit.

What are my options?

[n8n]

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

Suggested resources

Automatically matched to your question.

Docs:

• Manage execution data
• Control concurrency
• Fix memory issues

Forum:

• Execution runs for a long time (confirmed), then later shows “Error in ~6–8s” / “execution was interrupted” with no error details (loop-heavy workflow)
• Intermittent workflow execution failed under Load
• Simultaneous executions - What happens when the plan limit is reached?

@Anshul_Namdev, @jabbson - 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.

[Hammad_gaming]

Hi @Kayla_Campos Welcome!

Before you pay for an upgrade, it’s worth checking whether concurrency is actually the problem. When you go past the limit on Cloud the extra executions just queue and run in FIFO order, they don’t crash. So sitting at 20 concurrent shouldn’t produce what you’re seeing.

Crashed executions plus n8n switching the workflow off usually points at memory instead. If the instance runs out of RAM it restarts and anything mid flight gets marked as crashed, which would also explain why the same ones succeed when you retry them one at a time.

Understand concurrency | Deploy | n8n Docs

What status do the failed ones show exactly, and roughly how much data is each execution handling? If it turns out to be memory then more concurrency won’t fix it. One thing that might help either way is moving the heavy part into a sub-workflow, since sub-workflow executions don’t count towards the concurrency limit.

[kjooleng]

@Kayla_Campos

it seems like it is due to the sheer volume of executions

@Kayla_Campos

What are my options?

Hi @Kayla_Campos

This is the standard way to handle high-volume spikes without increasing concurrency. Instead of your workflow doing the “heavy lifting” immediately upon trigger, you split it into two distinct workflows.

• Workflow A (The Ingester): This workflow is triggered by your webhook/event. Its only job is to take the incoming data and write it to a “buffer” (a database like Supabase/PostgreSQL, a Google Sheet, or even an n8n internal data structure if you use a simple queue). This workflow finishes in milliseconds, meaning it releases its concurrency slot almost instantly.
• Workflow B (The Processor): This workflow runs on a Schedule Trigger (e.g., every 1 minute). It pulls a batch of records from the buffer (e.g., “Get top 10 rows where processed = false”), processes them, and then marks them as “processed.”

Why this works: You are decoupling the arrival of data from the processing of data. You can have 10,000 items hit Workflow A in one second, but Workflow B will only ever use 1 concurrency slot at a time, processing them at a steady, controlled pace.

[appunitsai]

Hey @Kayla_Campos ,

Welcome to the community first, second may I know how big is the workflow that you currently running ? like how many nodes are there and if there is a possibility to share the workflow it will help in finding what’s the issue and where we can improve, so far as @Hammad_gaming mentioned I think the problem is rather in the memory, can you share what you see in the executions tab?

Thanks

[Kayla_Campos]

Hi @appunitsai thank you!

I’ve uploaded some screenshots. One of the workflow, and two of the executions. It will work for a few days but then there will be lots of events / triggers at once and that causes it to error a bunch of times as you can see and then n8n turns it off. I don’t see any details around the errors in the actual executions.

[Hammad_gaming]

@Kayla_Campos

I review your screenshots, the timings help. Your good runs finish in 2 to 6 seconds but every failed one sits at around 57 seconds, which looks more like something timing out just under a minute than volume by itself. The once with no duration at all are probably crashed rather than errored, which is why there’s no detail when you open them.

If that’s what’s happening, more concurrency won’t fix it. What would help is not running one execution per Loops event, since a campaign send fires one per recipient and you get hundreds in the same second. Having the webhook write the payload somewhere and a scheduled workflow drain it in batches turns that into a handful of executions.

When you open one of the 57 second ones, does it show anything at all, even a red node?

[Anshul_Namdev]

Hi @Kayla_Campos Welcome!
Upgrading does raise the ceiling, just not the number you checked. Cloud resources scale with the plan tier: Pro-1 (10k) is 640MiB RAM and 20 millicore burstable CPU, Pro-2 (50k) is 1280MiB and 80 millicore. Concurrency stays at 20 on both, so that figure doesn’t move while memory doubles and CPU goes up four times.
20 millicore is the real constraint on a 25 node workflow. n8n’s own process averages around 180MiB, which leaves roughly 460MiB and that fraction of a core for everything in flight, so a Loops campaign firing 15 events into the same second means 15 executions competing for it. The 50k tier is the only Cloud change that lifts both at once.

Manage your data | Deploy | n8n Docs

More on how the tiers differ:

n8n Cloud Plans Breakdown: Starter, Pro, Business & Enterprise (2026)

[appunitsai]

Thanks @Kayla_Campos for sharing the screenshots, it’s now much better!

The reason for not getting errors is that you have done the below option:
On Error → Continue

Now based on the screenshots provided I don’t believe it’s a memory issue neither concurrent requests but rather the requests being done to Attio API, now based on Attio API docs here:

Handling rate limits - Attio Docs

rate limit is 100 requests per second for read requests and 25 requests per second for write requests.

Now there are multiple reasons for that issue, examples could be:

• Rate limiting
• Bad payload being sent to Attio

Let’s assume the data being sent are valid, Now how to fix the issue:
1- please change On Error → Continue to be either: Stop Workflow or Continue (using error output) I recommend going with Continue (using error output)

2- if we go with the Continue (using error output) option, now in the error route we may get something like this from Attio API response:

HTTP/1.1 429 Too Many Requests
Retry-After: Tue, 25 May 2023 14:42:01 GMT
Content-Type: application/json

{
"status_code": 429,
"type": "rate_limit_error",
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded, please try again later"
}

now we can parse the Retry-After header and then add a wait node and then retry the request again after the time being specified in Retry-After header, something like this:

Note I’ve used if node here as an example to check for the error being returned and in case it’s a rate limit error we go to the wait node, for sure we can use switch node …etc I’m just showing an example.

Most failures take ~57 seconds so it’s a timeout issue and I’m almost 100% sure it’s the API callings to Attio, so please can you do the above changes and share the results back?

Thanks

[Cloudrocket]

Nothing shown so far proves either an n8n memory limit or an Attio rate limit. A repeated run time near 57 seconds is a timing signature, not a cause. On Error: Continue can also hide the node response that would separate those cases.

For one controlled run, switch the Attio nodes to Continue (using error output) and capture the actual status, response body, and headers. For a crash with no duration, give Cloud Support the execution ID and timestamp and ask whether the instance restarted. Those are different failures and should not be tuned together.

Do not upgrade for concurrency. Both tiers discussed here keep the limit at 20. Upgrade only if Support confirms resource exhaustion, or if the controlled run shows the current compute tier is the bottleneck. If the error output shows 429, honor Retry-After and smooth the incoming burst before it reaches Attio.

[Kayla_Campos]

Thanks, I switched the Attio nodes to Continue using error output, workflow was still turned off after a few days due to crashes and it still doesn’t show any error, it shows it was successful.

[Aghassi]

That last part is the important one: it shows successful and it still stopped. When a run reports success and something is still wrong, the status field is not where the answer is.

I hit this in my own engine, not n8n, but the shape is the same. I found 27 broken branches in my workflow definitions. Some were silently skipped, some silently ran, and every run still finished as COMPLETED either way. On Error → Continue does the same thing here: it turns a visible failure into an invisible one.

What works for me was checking the output instead of the status. Put a node after Attio that asserts the response actually contains what you expect, and let the workflow fail on purpose when it does not. Then you see the real error instead of a green run.