What is the maximum timeout value for Http Node?
We have a use-case in our automation where we need to achieve parallel execution on given list of items using Webhook Trigger, Http Node, and the wait time will be 30-90 days.
Setting 30days as Http Node timeout is failing with below error, corresponding Webhook workflow is not getting executed.
””” The connection was aborted, perhaps the server is offline [item 0]
”””
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
hi @shakthipsg
What I’d do is return immediately from the first webhook and use a Wait node to pause the workflow, then resume it later by time or by a callback webhook. If you need a longer overall limit, set that at the workflow level, not in the HTTP node.
I wouldn’t use the HTTP Request node for a 30–90 day wait. It’s meant to wait for a response, not hold a connection open that long, and proxies or upstream servers will usually close it first.
We tried webhook callback, but it gets triggered when the first item execution completes.
Our use-case, we need to run N number of items in parallel in Webhook Trigger and make the Main workflow to wait until all the N executions completes.
With webhook callback, callback gets executed on very 1st item execution completes.
The maximum timeout for an HTTP node in n8n depends on the hosting environment. By default, I can manually configure it in the node settings (e.g., 300,000ms for 5 minutes). However, for very long-running tasks, we usually optimize the server’s reverse proxy (like Nginx) to prevent a ‘504 Gateway Timeout’ and ensure the workflow stays stable
@shakthipsg
I wouldn’t resume the main workflow from each item directly. I’d pass a shared jobId to all parallel executions, store the expected total N, and have each item mark itself complete in a shared store. Then the main workflow only continues when completed = N.
basically the issue is that http node isnt designed for long holds — youll end up with orphaned connections and timeouts. you need something external tracking which items are done, like a data store or separate api the workflow pings. hard to make the callback pattern work for parallel execution without a coordinator.
The timeout should be treated as no more than 1 minute. That’s a general practice in networking. Otherwise, any proxy/ALB/routers in between or the server itself may drop the connection.
Use a data table to store info about how many items have already been finished and how many are left.