n8n webhook timeout: why a slow AI agent breaks the call (and how to respond right away)

An n8n AI agent that chains several tool calls — document search, an LLM call, a database write — can legitimately take 10, 30, sometimes 60 seconds to respond. That's normal for an agent. It's also well beyond what most HTTP callers tolerate: Slack cuts the connection after 3 seconds if your slash command hasn't acknowledged, Cloudflare on the free plan closes the connection at 100 seconds with no exceptions, and a load balancer or a plain browser fetch() often gives up well before that. The classic result: the n8n execution finishes successfully in the logs, the agent did answer — but the caller has already seen a timeout error, or worse, retried the request and triggered the agent a second time.

This isn't a bug in n8n or in your prompt. It's a synchronous architecture applied to a process that isn't one.

Why an AI agent blows through webhook timeouts

A simple LLM call typically answers in one to a few seconds. An agent with tools (the AI Agent node — see our complete guide to the AI Agent node) chains several round trips: the model decides to call a tool, the tool runs, the result goes back to the model, which decides what to do next. Three or four iterations are enough to far exceed the one-second latency of a single call, with nothing actually broken — that's simply how a multi-step reasoning agent behaves.

A well-known study on users' tolerance for web latency, Nah (2004), A study on tolerable waiting time: how long are Web users willing to wait?, published in Behaviour & Information Technology, places the tolerance threshold without any visual feedback at around two seconds — and, more importantly, shows that a simple acknowledgment (a receipt, a progress indicator) meaningfully extends that threshold. That's exactly the principle behind the pattern below: it isn't the actual processing time that's the problem, it's the absence of an immediate response during that delay.

The Webhook node's three response modes

n8n's Webhook node exposes a Respond setting with three options:

• Immediately — responds as soon as the request is received, before the rest of the workflow even runs. Fast, but you can't return a computed result.
• When Last Node Finishes — the default setting, and the #1 cause of timeouts with an AI agent: the HTTP response only goes out once the entire workflow, agent included, has finished.
• Using 'Respond to Webhook' Node — the response goes out the moment execution reaches an explicit Respond to Webhook node placed in the flow, whatever happens afterward.

That third mode is what unlocks the asynchronous pattern: it decouples the moment the caller gets a response from the moment the agent actually finishes its work.

The pattern that fixes most cases: respond right away, process afterward

The principle fits in one sentence: acknowledge in a few milliseconds, then let the agent work in the background. Concretely, in n8n:

1. Webhook — response mode set to "Using Respond to Webhook Node".
2. Generate a job ID (a Code or Set node, a UUID) and write a "processing" row to a Supabase table — see our guide to connecting Supabase to n8n if that's not already in place.
3. Respond to Webhook — immediately returns { "status": "processing", "jobId": "..." } (HTTP 202 Accepted, more honest than a 200 for work still in progress). The n8n execution keeps running past this node: sending the HTTP response does not end the workflow.
4. AI Agent — runs next, with no time constraint tied to the original caller.
5. Update the Supabase row with the final result, then deliver it through one of the three channels below.

Delivering the result: callback, edited message, or a pollable status

• Callback URL — if the caller is itself a system (a third-party API, another n8n workflow), it supplies a callback URL in its initial request; an HTTP Request node at the end of processing posts the result there.
• Slack response_url — for a slash command or an interactive button, Slack provides a response_url valid for several minutes: acknowledge in under 3 seconds, then post the final message to that URL once the agent is done. This complements the human-wait pattern described in our article on approving requests with Slack buttons, for the case where it's the AI, not a human, that takes time to respond.
• Status endpoint — for a public API, the client polls GET /status/{jobId} (a second n8n workflow, triggered by a webhook, that simply reads the Supabase table) until the status flips to "done". That's the right pattern for a RAG question-answering API exposed to external clients, where the combined latency of document search and generation can vary widely from one request to the next.

The Wait node's webhook resume: the other direction of the problem

Don't confuse it with the pattern above: n8n's Wait node also has a "Resume: On Webhook Call" option, but in the opposite direction. Where the pattern above responds fast so the agent can then take its time, Wait in webhook mode pauses an already-running workflow until an external system calls back a resume URL — useful, for example, when a guided questionnaire bot is waiting on a human's validation at an intermediate step, or when a third-party service needs to finish a long process before the rest of the workflow can continue. The two mechanisms combine well in multi-step conversational agent workflows, but they solve different problems: the first protects the caller from a timeout, the second protects your workflow from needless active waiting.

Don't just raise the reverse proxy's timeouts

The most common reflex when facing a webhook timeout is to bump proxy_read_timeout on Nginx, tweak Traefik, or hope Cloudflare lets the request run longer — see our guide on exposing n8n over HTTPS behind Traefik or Caddy for those settings when they're actually the right lever. It's a patch, not a fix: Cloudflare caps an HTTP request's duration at 100 seconds on the free plan, with no way to raise it, and Slack will never negotiate its 3-second window no matter what your server does. Once several agents run concurrently under load, these long executions sitting and waiting for a response also tie up more workers — our article on queue mode with Redis covers how n8n distributes load as concurrent executions scale up. The asynchronous pattern fixes the problem at the root: the agent's duration stops being constrained by anyone but you.

Common pitfalls

• The Respond to Webhook node never gets reached. If the agent crashes before that node (an API error, an invalid credential), the caller is left hanging until its own timeout with no response at all. Place the acknowledgment before the agent, not after, and add an Error Workflow to mark the job as failed in your database if downstream processing errors out.
• The caller retries after a perceived false timeout. If your acknowledgment itself takes more than a few hundred milliseconds to go out (a saturated queue, a cold start), some clients resend the request and trigger the agent twice for the same request — the fix is described in our article on n8n webhook idempotence.
• An unprotected status endpoint. A sequential or guessable jobId lets anyone read other users' results; generate unpredictable IDs (UUID v4) and apply the same principles as in our guide to securing a publicly exposed n8n webhook.

Going further

This immediate-acknowledgment-then-async-processing pattern is exactly what powers the Compliance & Audit Pack (€149) for its guided questionnaire bot, where every exchange can keep the agent busy for several seconds without ever leaving the user waiting in silence, as well as the question-answering API in the RAG Assistant Pack (€119). If your agent is still set to "When Last Node Finishes" and you're seeing timeouts appear as soon as answers get more complex, that's the first setting to change before looking any further.