How to set timeout for workflows in n8n?

n8n does not have a built‑in “workflow timeout” setting that you can configure per workflow. The platform itself doesn’t expose a native feature like “stop this workflow after 30 seconds/minutes.” Instead, you control timeouts using a combination of n8n settings, node-level options, infrastructure settings, and manual timeout logic inside the workflow.

 

How you actually set (or enforce) timeouts in real n8n workflows

 

You enforce workflow timeouts indirectly. The main reliable options are:

• Node-level timeouts (for HTTP Request, Execute Command, etc.)
• n8n instance-level timeout via environment variable N8N_EXECUTIONS_TIMEOUT
• Manual timeout pattern using Wait + check logic
• Reverse timeouts (set via external systems calling your webhook with their own timeout)

Below is how each actually works in production.

 

n8n server-level timeout (the only real "global timeout")

 

You can stop long-running executions by setting the environment variable N8N_EXECUTIONS_TIMEOUT. If n8n sees that a workflow has been running longer than this number of seconds, it will abort it.

• This affects all workflows.
• It only works if the workflow is still running inside n8n, not waiting externally (like a Wait node with webhook).
• Useful when you want to prevent runaway loops.

# Example: stop any workflow after 30 minutes (1800 seconds)
export N8N_EXECUTIONS_TIMEOUT=1800

In Docker:

environment:
  - N8N_EXECUTIONS_TIMEOUT=1800

Once set, n8n will kill any execution that exceeds that runtime.

 

Node-level timeouts (most commonly used, very reliable)

 

Several nodes let you specify a timeout for the operation itself. This is usually the real solution because most long-running workflows get stuck waiting for an external API.

• HTTP Request node: timeout (ms)
• Execute Command node: timeout (s)
• Webhook response timeout from the caller side

Example: in an HTTP Request node, under Options, set:

• Timeout = 15000 (15 seconds)

This prevents the workflow from hanging waiting on slow APIs.

 

Manual “soft timeout” pattern inside the workflow

 

This is a common production pattern when you want a workflow-level timeout even though n8n doesn’t offer one natively.

Pattern:

• Use a Set node to store the start time.
• Loop with a Wait node (e.g., 30 seconds).
• At every iteration, compare current time with start time using an If node.
• If exceeded, exit gracefully, send alert, stop loop.

Example expression you’d use in the If node:

// Returns difference in seconds between now and start time
(new Date().getTime() - new Date($json.startTime).getTime()) / 1000

This is simple, reliable, and gives you workflow-specific timeout logic.

 

Timeout caused by infrastructure (common but not obvious)

 

Sometimes the “timeout” comes from outside n8n:

• Your reverse proxy (NGINX/Traefik) may kill requests after X seconds
• Your cloud provider kills idle containers
• Your webhook caller (Stripe, Shopify, etc.) stops waiting after 5–10 seconds

These do not stop the workflow itself, they just break the input/output expectations. But developers often misinterpret these as n8n timeouts.

 

Putting it together (what we actually do in production)

 

In real deployments, a safe setup looks like:

• Set N8N_EXECUTIONS_TIMEOUT to something reasonable (e.g., 30–45 min).
• Set node-level timeouts for everything hitting external APIs.
• Use the manual soft timeout pattern when a workflow loops or polls.
• Ensure your reverse proxy timeout is aligned with workflow needs.

That’s how you effectively control workflow runtime without relying on nonexistent per-workflow timeout settings.