n8n webhook timeout: respond immediately, then do the work
On n8n Cloud a webhook that hasn't answered in 100 seconds fails with a 524. Set Respond to Immediately, do the slow work after, and dedupe sender retries.
An n8n webhook times out when the caller stops waiting before the workflow answers. On n8n Cloud, a webhook that doesn't respond within 100 seconds fails with a 524, and the sender may give up sooner. The fix is to answer first: set the Webhook node's Respond option to Immediately, or put a Respond to Webhook node right after the trigger, then run the slow steps and ignore duplicate deliveries.
n8n facts come from its Webhook node, Webhook common issues, Respond to Webhook and webhook URL pages. The sender example is Sume, from Webhooks and Run webhooks. All were read on 2026-09-29. Sume has no n8n node of its own; it POSTs to your webhook URL over HTTPS.
Why does my n8n webhook time out?
The Webhook node's Respond setting decides when the caller gets an answer. With When Last Node Finishes, the sender waits for the whole workflow, including any slow API call or Wait node in it. n8n Cloud sits behind Cloudflare, and n8n's docs say a webhook that doesn't respond within 100 seconds fails with status 524. For longer work, the same page suggests one webhook that starts the process and answers at once, and a second one the caller polls for the result.
| Respond option | When the caller gets an answer | Timeout risk |
|---|---|---|
| Immediately | At once: the response code and the message "Workflow got started" | None from the workflow's length |
| When Last Node Finishes | After the last node runs, with its output | The whole workflow must finish inside the sender's limit |
| Using 'Respond to Webhook' Node | When that node runs; place it early to answer early | Only the nodes before it count |
How do I respond immediately and keep processing?
- Simplest: open the Webhook node and set Respond to Immediately. The rest of the workflow keeps running after the reply.
- If the caller needs a specific body or status, set Respond to Using 'Respond to Webhook' Node and place that node right after any quick validation. It runs once, with the first incoming item.
- Know the edge cases: if the workflow errors before the Respond to Webhook node runs, n8n returns a 500; if the workflow finishes without running it, n8n returns a standard message with a 200.
- Use the Production URL for real senders. The Test URL only listens for 120 seconds after you select Listen for test event.
Why did my workflow run twice?
Because the sender retried. A sender that counts a slow answer as a failed attempt sends the event again, so a workflow that answers late can run once per attempt. Sume is a concrete example: its job webhooks allow 10 seconds per attempt, make up to 10 attempts with a fixed 30-second gap, and retry any non-2xx or network error. Run webhooks have the same 10-second budget, and a 3xx counts as a failed attempt.
So answer with a 2xx right after you've recorded the event, then do the work. Dedupe on the sender's event id: job_id for Sume job webhooks, request_id for run webhooks, which is the same on every retry of the same run. Resume a Wait node on a Sume webhook shows the other pattern, where n8n starts the job and waits for its callback.
Can Sume call a self-hosted n8n webhook?
Only on a public HTTPS URL. Sume's docs reject localhost, private-network and non-HTTPS webhook URLs, and in current code an explicit non-default port is refused too, so https://n8n.example.com:5678/webhook/… won't be accepted. n8n's docs note that n8n listens on port 5678 internally; behind a reverse proxy on port 443, set N8N_WEBHOOK_URL so n8n shows and registers the public URL. Webhook URL rejected? lists every rule.
Sources
Related posts
More in Integrations
- p-retry npm: retry a paid API POST and stop on errors
p-retry reruns an async function with exponential backoff. Throw AbortError on answers a resend can't fix, and keep one Idempotency-Key per job.
- PHP cURL POST JSON with a Bearer token
json_encode the body, pass the string to CURLOPT_POSTFIELDS, set Content-Type and Authorization headers, then check the status: cURL won't fail on a 4xx.
- Polly retry policy for an HttpClient POST to a paid API
A Polly retry for a paid POST: handle only transient failures, back off exponentially with jitter, honor Retry-After, and resend one idempotency key.
- Power Automate HTTP Webhook action: wait for a callback
The HTTP Webhook action sends a subscribe request with the flow's callback URL, then pauses until something POSTs to it. How to use it with a slow API.
Written by Sume