← All guides

Why your n8n AI agent's HTTP calls time out (and how to fix them)

AI agent workflows make far more HTTP calls than classic automations: model APIs, tool endpoints, webhooks, vector stores. When those calls are slow, n8n's defaults turn intermittent slowness into failed executions.

What the default behavior is

Every HTTP Request node in n8n has an Options → Timeout setting, in milliseconds. The field pre-fills 10,000 ms when you add it — but if you never add the option at all, current n8n versions fall back to 300,000 ms (5 minutes) in code (HttpRequestV3.node.ts: set default timeout to 5 minutes). Either way, the default is doing something you did not choose: a hung request stalls the execution for up to five minutes, burning concurrency, and big-context model calls can still hit the 300-second ceiling. Set the timeout explicitly per node instead of inheriting either default.

There is also a workflow-level execution timeout (workflow Settings → Timeout Workflow). A node timeout that is too generous can push the whole run into the workflow timeout instead. Set both deliberately.

Fix 1: set an explicit timeout per node

Open the HTTP Request node → Options → add Timeout. Use 10,000 ms for fast health checks, 30,000–60,000 ms for slow model or embedding APIs. In exported workflow JSON this appears as:

{
  "name": "Call LLM API",
  "type": "n8n-nodes-base.httpRequest",
  "parameters": {
    "method": "POST",
    "url": "https://api.example.com/v1/chat",
    "options": { "timeout": 60000 }
  },
  "onError": "continueErrorOutput"
}

Fix 2: add retries — but only for idempotent calls

Select the node → Settings tab → enable Retry On Fail, then set Max Tries and Wait Between Tries. In JSON:

"retryOnFail": true,
"maxTries": 3,
"waitBetweenTries": 2000

Only retry requests that are safe to repeat (GETs, idempotent POSTs). Retrying a payment or record-creation call can double-apply the side effect.

Fix 3: decide what a failure means

Every node has an onError behavior. The default, stopWorkflow, halts the entire execution on the first failed call. For agent workflows, continueErrorOutput routes the failure to the node's error output so a downstream node can fall back, log, or escalate — the agent keeps working instead of dying.

Diagnose it in the exported JSON

Export the workflow (⋮ menu → Download) and run this jq one-liner to find every HTTP node missing a timeout, error handling, or retry:

jq -r '.nodes[]
  | select(.type == "n8n-nodes-base.httpRequest")
  | "\(.name): timeout=\(.parameters.options.timeout // "NOT SET")
      onError=\(.onError // "stopWorkflow (default)")
      retryOnFail=\(.retryOnFail // false)"' workflow.json

Expected output for a healthy workflow:

Call LLM API: timeout=60000 onError=continueErrorOutput retryOnFail=true
Fetch embeddings: timeout=30000 onError=continueErrorOutput retryOnFail=true

Any line showing NOT SET is a node running on the invisible 5-minute code fallback instead of a timeout you chose; a hung request there stalls the whole execution. Any line showing stopWorkflow (default) is a node that halts the entire run on the first failed call.

Common failures

• No timeout set on slow LLM calls. An unset timeout falls back to 5 minutes in code, so a hung request stalls the execution instead of failing fast — and big-context calls can still hit the 300-second ceiling.
• No onError handling. One flaky webhook stops a 40-node agent run.
• Retry storms. Retrying a non-idempotent POST, or retrying aggressively against a rate-limited API, turns one failure into many — and can get the API key throttled.
• Timeout set too high. A 5-minute node timeout on every node means the workflow-level execution timeout fires first, and the error message points at the wrong place.

Go further

The free n8n-workflow-linter checks exported workflow JSON for exactly these smells — missing timeouts, missing error handling, and more. For the full treatment (10 importable reliability workflows, a failure-simulation eval harness, readiness scoring, and a 37-page production playbook), see the n8n Reliability Guard ($99, one-time).