n8n HTTP Request Timeout and "Aborted" Errors: Causes and Fixes

A timeout means the HTTP Request node gave up waiting. The cause can be on the API side (a slow endpoint, a big export), on the network, or in your configuration. The fix depends on which, so start by reading the error and timing the call.

What the Timeout option actually measures

According to the documentation, Timeout is how long the node waits for the server to send response headers and start the response body. Requests that exceed it are aborted. It is not a limit on the total transfer time of a large body once it has started.

Set it in the HTTP Request node: Add Option > Timeout, in milliseconds. n8n fills in 10,000 ms when you add it; 60000 is one minute.

Fix 1: raise the timeout for a known slow endpoint

Reports, exports and AI endpoints can take tens of seconds. If the API documentation says an endpoint may take 45 seconds, set the timeout above that, for example 90000. Do not set huge values everywhere: a hung request then blocks the execution for that long.

Fix 2: retry intermittent failures

Networks and APIs fail occasionally. In the node Settings:

1. 1 Turn on Retry on Fail.
2. 2 Max Tries: 3.
3. 3 Wait Between Tries (ms): 5000 or more.

Only retry requests that are safe to repeat. Retrying a "create invoice" call after a timeout can create two invoices if the first one actually succeeded. For such calls, check whether the record exists before retrying, or use the API's idempotency key if it offers one.

Fix 3: ask for less per request

• Reduce the page size and use pagination to fetch the rest.
• Filter on the server (date ranges, status) instead of downloading everything and filtering in n8n.
• With many input items, use the Batching option: Items per Batch and Batch Interval (ms) spread the load.

Fix 4: make long jobs asynchronous

Many APIs that generate big files work in two steps: a request that starts a job and returns an ID, then a status endpoint. Build it the same way in n8n:

1. 1 HTTP Request: start the job, store jobId.
2. 2 Wait node: 30 seconds.
3. 3 HTTP Request: get the status.
4. 4 IF node: done? Continue. Not done? Loop back to Wait, with a maximum number of attempts.

This pattern never holds a connection open for minutes, so timeouts disappear.

Fix 5: check the network path (self-hosted)

If every call to one host times out:

• Test from inside the n8n container: docker exec -it n8n wget -qO- https://api.example.com/health.
• Check whether your server needs a proxy for outbound traffic. The node has a Proxy option, and the HTTP_PROXY, HTTPS_PROXY and ALL_PROXY variables apply globally.
• A refused connection is a different error. See ECONNREFUSED in n8n.

Other limits that look like timeouts

• Webhook callers on n8n Cloud time out after 100 seconds (Cloudflare 524), even if your HTTP calls inside the workflow are fine.
• Workflow execution timeout can be set per workflow in its settings, and self-hosted admins can set instance limits. A workflow stopped by it is a different error from a request timeout.
• Code node tasks on task runners have their own limit (N8N_RUNNERS_TASK_TIMEOUT, 300 seconds by default).

Worked example: a report export that takes three minutes

An analytics API builds a CSV export on request and can take several minutes. A single request with a huge timeout is fragile. Build it as a polling loop:

1. 1 Start export: POST /exports, body with the date range. Response: { "id": "exp_81", "status": "queued" }.
2. 2 Wait: 30 seconds.
3. 3 Check status: GET /exports/{{ $('Start export').item.json.id }}.
4. 4 IF: {{ $json.status === 'done' }}.
5. 5 True: Download: GET the file URL with Response Format: File.
6. 6 False: back to Wait, through a counter that stops after 20 attempts.

For the counter, a small Code node before the IF works:

const attempt = ($input.first().json.attempt ?? 0) + 1;
if (attempt > 20) throw new Error('Export not ready after 10 minutes');
return [{ json: { ...$input.first().json, attempt } }];

Each request is short, so no timeout is ever hit, and the error message tells you exactly what happened if the export never completes.

Diagnosing the error message

Idempotency: retry without duplicates

Retrying a GET is harmless. Retrying a POST that creates something can create it twice if the first attempt succeeded but the response was lost. Options:

• If the API supports an idempotency key header, send a stable value per record (for example the record ID). The API then ignores duplicates.
• Otherwise, search before create: look the record up first, and only create it if it does not exist.
• Keep Retry on Fail off for create calls and handle failures in an error branch.

Troubleshooting table

Production checklist

• Timeout set deliberately on slow endpoints, default elsewhere.
• Retry on Fail only on safe-to-repeat calls.
• Long exports built as start / wait / check loops with a maximum.
• An error workflow so a timeout at 3 a.m. becomes an alert, not a silent gap. Our workflow failure cost calculator estimates what silent failures cost you.

Frequently asked questions

What is the default timeout of the n8n HTTP Request node?

When you add the Timeout option, n8n fills in 10,000 ms (10 seconds). Raise it explicitly for endpoints you know are slow.

Does the Timeout option limit large downloads?

It limits the wait for the server's first response (headers and start of the body), not the full transfer time of a body already streaming.

Should I enable Retry on Fail for every request?

No. Only for requests that are safe to repeat. A retried create request can produce duplicates if the first attempt succeeded.

How do I handle an API that takes several minutes?

Use an asynchronous pattern: start the job, wait with a Wait node, poll the status, then fetch the result.

Does Retry on Fail retry on timeouts?

Yes, a timeout is a failure of the node, so Retry on Fail tries again with the wait you set.

Can I set a timeout for the whole workflow?

Yes, in the workflow settings (Timeout Workflow). It stops the execution after the duration you set, separately from each request's timeout.

Why does the request time out only in production?

Production often sends more items at once or calls the API at busy hours. Add batching and retries, and check the API's rate limits.

Steve, founder of PURIST

Steve founded PURIST, a workflow automation studio working with n8n, Make and Claude AI, and is the point of contact on every project. Prices and features in our articles come from vendor documentation and public pricing pages. How we research and score tools.