n8n API Timeout and Silent Retry Failures

1. Set explicit timeout and keep it below the caller

• Set the HTTP Request node timeout to 10–15s, not infinite. Let the workflow handle the error branch.
• If a proxy times out at 60s, your node must time out first so you can retry with backoff.

2. Idempotency before retry

• Before enabling retry, add an idempotency key tied to the business action, e.g. shop:<id>:order:<id>, not the execution id.
• Without it, a timeout that actually wrote will double-write on retry.

3. Backoff, not hammer

• Use Wait + loop with 1s → 2s → 4s backoff, max 3 attempts. Immediate retry triggers rate limits.
• Honor 429 Retry-After if the API sends it. Parse it and Wait exactly that long.

4. Pagination that actually pages

• Most APIs return next_cursor or Link: rel=next. Map that output to the next request input. A common bug is reading the cursor but never feeding it back.
• Test with two pages of mock data before wiring the real API.

5. Verification

Run the workflow with pinned data for 2 pages, then live with a throttled API mock. Confirm: no duplicate writes, backoff delays appear in Executions, and pagination stops at the last page.

Subject: n8n api timeout — diagnostic request

Describe:
- Webhook or HTTP Request node + method/path
- Test URL works? Production URL status (curl -i)?
- Activation + queue mode? Postgres SSH in use?
Paste sanitized config (redact secrets) and I will reply with the exact fix.
— myn8n-automation.org/guides/n8n-api-timeout/

Truth disclosure: This guide shows owned capability and a demo eight-node GitHub activity → Claude-assisted weekly summary → Slack/Discord workflow with local JSON/README/image evidence. No client result, sale, review, accepted bounty, earnings, or production customer outcome is claimed. The named preview businesses did not commission this work.