The Webhook Timeout Trap: Why My n8n Webhook Stopped Timing Out (Respond First, Work Later)

Description and use

Responding immediately, deduplication, and separate error handling in n8n eliminated duplicate orders and emails and stopped sender retries.

Problem

The sender’s 30‑second timeout caused the n8n webhook to retry, producing duplicate orders and emails while the workflow ran 60–90 seconds.

Outcome

Fast acknowledgment and idempotent processing eliminated duplicate orders and emails, reduced sender retries to zero, and improved reliability.

Workflow

• Webhook Trigger → Respond to Webhook (200, {"received":true,"event_id":"{{ $json.id }}"}) → Dedupe check (skip if event_id seen) → LLM call → Database write → Confirmation email

Evidence

The workflow validates the order, calls an LLM to generate a fulfillment summary, writes rows to my database, sends confirmation emails. About 60–90 seconds of real work, end to end.

Source

My workflow took 90 seconds to answer. So the sender did exactly what senders do – it retried. Twice. Three "successfully processed" runs, three confirmation emails, three database rows for the same order.

Source

The webhook’s only job is to acknowledge receipt; the real work happens after the response.

Source

Responding fast is only half the fix. It creates two obligations: 1. Idempotency is now mandatory, not optional. 2. You need to know when background work fails.

Source