Hi,
I’ve recently upgraded my N8N cloud plan, going up from 5 to 20 concurrent workflows. This is too many and breaking my API calls, and I can’t find a way to reduce this. Is there a way?
Thanks.
welcome to the n8n community @rhysdyson
Unfortunately, there isn’t a setting in n8n Cloud to manually lower that limit, but I’ve found you can control the flow within the workflows themselves to keep things from breaking.
If your executions come from a list of items, I’d suggest using an Execute Workflow node to call a sub-workflow with the “Wait for execution to finish” option enabled. This forces everything to run one by one. Another way is the Redis lock approach, where you use a Redis node at the start to check for a specific key; if it’s there, you stop or wait, and if not, you set the key and delete it once you’re done.
I’ve also seen people use a self-deactivation trick with the n8n API node. You basically have the workflow deactivate itself as the first step so no new triggers can start until it reactivates itself at the very end. If you’re dealing with a ton of webhooks, you might honestly need an external queue like RabbitMQ to act as a buffer so you can pull tasks at a pace your API can actually handle.
Hope this helps!
Hi @rhysdyson Welcome!
Although i would say that if that is breaking some of your current flows, downgrading your plan is a better take, i think for the API calls the farthest you can go is use the LOOPED item with wait(2-8s) and that would provide some help, else the concurrency if the flows are hitting a service that would surely get temporarily block.
yeah this is a classic problem when you scale up. the sub-workflow trick that tamy mentioned is solid Execute Workflow with "wait for sub-workflow on, and it’ll process things one at a time instead of hammering your API all at once.
what i usually do though is way simpler just Loop Over Items with a Wait node inside it. if your API allows like 10 requests per minute, stick a 6 second wait between each item. done. no redis, no rabbitmq, no overengineering.
also — are you sure it’s actually concurrency that’s the issue? sometimes it’s just the same workflow getting triggered multiple times at once (especially with cron). if that’s the case you can add a quick check at the start hit the n8n API to see if another execution of the same workflow is already running, and if so just exit early. way less fragile than the self-deactivation thing.
what API is giving you trouble btw? some of them have pretty specific rate limit quirks that might need a different approach.