Hi
Just some advice I need, what would be a reasonable timeout period for a workflow. Incase maybe you have a webhook is getting a bunch of traffic and you want the queue to be cleared instead of just quickly timing out?
This is a bit of a tricky one to answer - the short answer is that it depends 
So this is checked after each node execution only. Let’s assume you have a workflow like this:
If you set your workflow timeout to 2 minutes, but the Set node runs 10 minutes, the execution would only be cancelled after the Set node finishes (so 10 minutes).
n8n does have some default timeouts on cloud - you can find these here:
Does that help?
Hi Emerald
What timeout setup applies to the webhook? Does it use the settings timeout or does it also have a mind of its own?
Hi @Keep_Innovations - the webhook trigger doesn’t have a timeout setting of its own, but a system calling the webhook might have a maximum wait time for a response.
I have set my scenarios to do the max 5min since I am on starter. However what occurs to n8n webhooks in cases of multiple requests incoming? Are they queued and one done after the next or what occurs?
@Keep_Innovations In the case of multiple requests coming in at once, they’ll be processed in parallel.
If you need queueing, you’d need an external system (something like hookdeck) for your webhooks, or self-host n8n in queue mode.
What do you mean by parallel? Also if you decide to self host, does this mean I have to recreate all my workflows again? Whats the transition process for such cases?
While n8n is designed to execute workflows and nodes in a sequence, if multiple webhook triggers fire, n8n will try to run the workflow for each webhook trigger. Multiple executions then may fire at the same time if more than one request has been sent to the webhook, since those triggers try and respond instantly.
Hope that helps!
So the workflows will still run and the webhook knows how to manage them essentially is what you mean? Ideally it would process instantly however if a case like 5 come at the same time it will fire all of them and try to run each request.
The workflows should still run. Five requests at the same time should be fine in most cases, but this heavily depends on the actual workflow you’re running. If you test this and you find that some workflow executions are dropped, you may need to also use that external queuing system I mentioned 
1 Like
A workflow that creates a receipt and sends back a receipt link to the client is an example of one of the things I am doing. I wish you could introduce scaling features or allow us to pay more for queuing features and scaling the capacity of our instances, rather than pay for even more services.