n8n Webhook Responds Slowly (or Times Out) Even Though the Real Work Is Fast¶
The Problem¶
A webhook-triggered workflow has a "Respond to Webhook" node (in responseNode mode) running in parallel with another node that does something slow or occasionally-failing — a slow API call, or in the case that motivated this article, an email-send node with a broken SMTP credential that spends 1–3 seconds retrying before failing.
Symptom: the webhook caller sees the response take as long as the slow parallel node, not as long as the fast one — sometimes exceeding the caller's own timeout — even though "Respond to Webhook" should, in principle, be independent of its sibling.
The wrong fix¶
It's tempting to assume n8n executes a node's outgoing connections in the order they're listed, and that reordering the connections (moving "Respond to Webhook" first) will make it run — and respond — first. This does not work. Reordering the connections array via the API (or dragging nodes around the canvas) does not change execution order for parallel branches off the same source node. A workflow republished with "Respond to Webhook" listed first will still show identical response-time behavior to before the change — confirmed by direct testing, not assumed.
The actual fix: make it a real sequential dependency, not a reordered parallel one¶
Parallel branches off the same node are not a race — whichever branch n8n happens to execute second still has to finish before anything downstream of it runs. If you need the webhook response to be genuinely independent of a slow/unreliable sibling node, that sibling can't be a sibling — it has to be downstream of "Respond to Webhook" in the graph:
not:
With the strict chain, "Respond to Webhook" is structurally guaranteed to execute (and flush the HTTP response) before the slow node even starts, regardless of how n8n schedules parallel branches internally. The side-effect node still runs afterward in the same execution — it just can no longer block the response.
Why this matters even after "fixing" the underlying cause¶
In the case that surfaced this: the slow node was an email send with a bad SMTP password. Even after fully disabling that node (not just reordering it), a webhook under repeated new-connection load kept showing an elevated failure rate for a while — turned out to be a mostly-unrelated, coincidental network issue on top of the real workflow bug. The lesson generalizes: verify each fix independently rather than assuming the most recently-changed thing explains 100% of the symptom. Publish, then re-test with a fresh measurement — don't reason about whether a change "should" have worked.
Verification¶
- After restructuring, time the webhook response specifically (not just check for a 200) — it should now be near-instant regardless of what the downstream side-effect node is doing.
- Confirm the change is actually live: n8n workflow edits via the API create a new draft version that is not automatically active. Check
activeVersion.sameAsDraft(or just re-fetch the workflow) — a workflow update that "succeeded" can silently leave the old version serving production traffic. Explicitly publish/activate after every structural change and re-verify against the live endpoint, not the draft.
Related¶
- netdata-n8n-enriched-alerts — the specific workflow this pattern applies to; its "Send Enriched Email" node is the one that motivated this article and should be re-enabled only after being restructured this way, not put back as a parallel sibling.