An automation built in n8n can already say "done" — and still do the exact same thing again.

The exact clicks

1. Open your workflow's Webhook (trigger) node and check its 'Respond' setting — if it says 'When Last Node Finishes', the reply is held until every node in the workflow completes.
2. Time a real run in the Executions panel. If it regularly takes more than a few seconds, whatever calls this webhook may already be timing out and retrying on its own.
3. Change the Webhook node's 'Respond' setting to 'Using \'Respond to Webhook\' Node'.
4. Add a 'Respond to Webhook' node immediately after the trigger, before any real work (sending an email, creating an order, calling another API) — this sends the reply the instant the event arrives.
5. Move every node that does real, side-effect-causing work to run AFTER the Respond to Webhook node, not before it.
6. Re-run a real test and confirm in the Executions panel that the response fires immediately, while the rest of the workflow still completes normally afterward.
7. (Optional) If the sender still shows retry attempts in its own logs, add simple de-duplication (checking an incoming ID against a short-lived store) as a second layer, not a replacement for responding fast.

What changes

• This is standard, current n8n behavior — verified live this session against n8n's own Webhook and Respond to Webhook node docs and a live Community forum thread describing this exact failure mode.
• n8n Cloud also hard-cuts an unanswered webhook at 100 seconds (a 524 response) — moving the reply earlier avoids that limit entirely, it isn't just about the caller's own timeout.
• This is a different failure than a node's own retry setting replaying one step (see episode 25) — here the TRIGGER fires the whole workflow again from outside, because nothing told it the first attempt was received.

What it will not do

• This stops duplicate runs caused by a slow reply; it does not protect against a sender that retries for a different reason (e.g. its own network error) — de-duplication is the real fix for that, not response timing alone.
• Moving the reply earlier means the caller can no longer see the workflow's own output in that response — if the caller genuinely needs the result synchronously, this tradeoff needs a different design (e.g. polling a status endpoint).
• This does not undo damage from duplicate runs that already happened — check for and clean up any real double-sends before assuming the fix alone is enough.