How to Fix n8n HTTP Request ETIMEDOUT and ECONNABORTED Timeouts in Loops
What broke, and why
A workflow loops over about 510 Attio deals and calls the Attio API twice per deal. A single call takes 170 to 430 ms, yet inside the loop some requests die with connect ETIMEDOUT 172.66.165.206:443 or timeout of 8000ms exceeded (ECONNABORTED). The status pages for n8n, Attio, and Cloudflare show no incident, and that is the first clue: nothing is down.
The cause is the connection pattern, not the API. At batch size 35, each iteration fired roughly 70 near-simultaneous TLS handshakes at a Cloudflare edge IP, and the storm tripped over itself. connect ETIMEDOUT means the TCP handshake never finished, so the request never reached Attio at all. A reply in the n8n community thread put it plainly: “ETIMEDOUT on connect usually means too many parallel connections, not a slow API.” The numbers fit: 510 deals times 2 calls is 1,020 requests, and batch 35 opens about 70 connections per iteration against about 10 at batch 5. The poster ran n8n 1.123.89 on Cloud and had already tried 5 retries and a 15-second timeout, which helped only partly.
Quick answer
Lower the Loop Over Items batch size from 35 to 5, raise each HTTP Request node’s timeout from 8,000 to 30,000 ms, set a 100 ms batch interval, and retry 3 times with a 5 second wait.
The hard part is taming the connection rate, not making any single request faster.
Checked on 2026-11-15 against the n8n community thread from 2026-11-12, the n8n HTTP Request node documentation, and the Loop Over Items documentation.
The fix
Change four settings. No new nodes, no rebuild, no code:
Loop Over Items node
Batch Size: 35 -> 5
HTTP Request node (both of them), Options tab
Timeout: 8000 -> 30000 (milliseconds)
Batching: Items per Batch 5, Batch Interval 100 (milliseconds)
HTTP Request node (both of them), Settings tab
Retry On Fail: on
Times: 3
Wait Between Tries: 5000 (milliseconds)
The n8n HTTP Request node documentation, checked 2026-11-15. Timeout and Batching live further down the page, under Node options.
The smaller loop batch is the main fix: it cuts concurrent handshakes per iteration from about 70 to about 10. The 30-second timeout only helps once a connection is open; it does nothing for ETIMEDOUT by itself. The 100 ms batch interval spaces requests inside each batch, so the handshakes do not all start in the same instant. Retries are the safety net: 3 tries with a 5-second wait. The poster ran 5 retries and it only partly helped, because each extra retry adds handshakes to a saturated path.
One thing to skip: the thread also mentions a dedicated Rate Limit node. We could not verify a built-in Rate Limit node in n8n; the docs list no such core node, so use the HTTP Request node’s own Batching interval instead. The original workflow’s 3-second Wait node did not help either: it pauses after each iteration, not between the requests inside it. For the general retry pattern, see our n8n error handling guide.
Pitfalls that make the fix look broken
| Symptom after the fix | Likely cause | What to do |
|---|---|---|
| Timeouts continue, unchanged | Only the timeout was raised | ETIMEDOUT fails before any response. Cut the loop batch size to 5 first. |
| Failures drop, then return at scale | Loop batch cut, but HTTP node batching left off | The HTTP node still fires every item it receives at once. Set Items per Batch 5 and Batch Interval 100 too. |
| Errors move to a different item each run | Retries set to 5 with a short wait | Each retry adds handshakes to a saturated path. Use 3 tries with a 5-second wait. |
| “It worked yesterday” after no change | Shared Cloud egress IPs | On n8n Cloud you share egress IPs with other tenants, so the same workflow can fail on a busy hour and pass on a quiet one. |
| Duplicate records after a retry | Retry on a POST, PUT, or PATCH | A retry re-sends the write. Check for idempotency-key support before enabling retries on writes. |
How to verify the fix
First run a 20-deal slice and check the execution log for zero failures and no timeout of 30000ms exceeded entries. Then run all 510 deals and check the same log. If timeouts persist, drop the batch size to 1 and re-run the slice; that isolates concurrency from everything else.
Test before you rely on it:
- Run the 20-deal slice first and confirm zero timeouts.
- Note the slowest single call; over 10 seconds means the API itself is slow, not the loop.
- If any call writes data, confirm no duplicates appeared after retries.
- Check the log after the first full run, not just the green checkmark: a retry that succeeds still hides a flaky connection.
When this does not apply
This fix does not apply if a single call fails outside any loop: with no concurrency, the fault is DNS, credentials, or the endpoint itself. It also does not apply to 429 or 403 errors: those are rate limiting and authorization, a different problem with a different fix. If a single call genuinely takes more than 30 seconds, raise the timeout further or switch to a webhook callback instead. On a self-hosted instance, check your own firewall or NAT connection limits first: the same storm can happen on your own egress. For the bigger picture, see our n8n complete guide.
Frequently asked questions
Why did the n8n, Attio, and Cloudflare status pages show no incident?
Nothing was down. connect ETIMEDOUT means the TCP handshake never finished, so the request never reached Attio. The failure happened on the path between n8n Cloud and the Cloudflare edge, which no vendor status page reports as an incident.
Does raising the timeout alone fix ETIMEDOUT?
No. The timeout only matters after a connection is established. ETIMEDOUT on connect fails before that point, so a longer timeout changes nothing by itself. You must also cut the batch size so fewer handshakes happen at once.
Should I use a batch size of 1 instead of 5?
Batch size 1 is the safest setting and a good first test, but it makes a 510-deal loop slow: 1,020 calls at roughly 170 to 430 ms each take 3 to 7 minutes before retries. Batch size 5 keeps the loop fast while cutting concurrent handshakes from about 70 per iteration to about 10. Start at 5, and drop to 1 only if timeouts persist.
Will Retry On Fail cause duplicate writes?
It can, on POST, PUT, or PATCH calls. A retry re-sends the whole request, and if the first attempt actually reached the API but its response was lost, the write happens twice. For read-only GET calls like the Attio lookups in this case, retries are safe. For writes, check whether the API supports idempotency keys before turning retries on.