Recursive calling using webhooks

As part of a bigger project i want to dive into the possibilities of recursive calling of workflows. I started with this test. The workflow is published. In the node Call_Again I am using the production URL. WHen I check Executions I see 5 instances of the workflow running. But i would have expected that after 9 runs, as checked in the if statement, the workflow would stop calling itself. Somehow, it does not run as I expected. Where is my misunderstanding of how things work in N8N? Thnks

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Better to use recursive calling with the Execute Workflow node, because with a webhook, you may get unpredictable results (e.g., the ALB starts to think you are DDoS-ing the service, or the service may run out of free sockets (if there are a lot of webhook calls), and other issues)

Hello @Jitse_Schaafsma ,

It’s not a bug in your logic—it’s just how n8n manages traffic.

You have a chain of workflows waiting on each other. Execution #1 calls #2 and waits. Execution #2 calls #3 and waits. By the time you get to #5, all your available “concurrency slots” are full of waiting workflows, so #6 can’t start.

To fix this : Change the pattern from a Chain to a Relay Race .

  1. Add a “Respond to Webhook” node immediately after your Up_Var node (before the If node).
  2. Configure it to respond with “OK”.

Now, as soon as Execution #2 starts, it tells Execution #1 “I got this,” allowing #1 to finish successfully and free up its slot. You’ll never use more than 2 slots at a time!

Hello @Jitse_Schaafsma

From what I understand about your needs, I recommend running an internal loop without having to execute an HTTP Request, to avoid blocking your worker queue / webhook parity.

Create a workflow that includes a loop limiter based on $runIndex, and check whether that helps you.

If it does, please rate my answer.