Execution Hanging: Finding Stuck Executions, Configuring Timeouts

In n8n you see an execution that simply never finishes. The status stays stuck on "Running" or "Waiting" even though the workflow should have completed long ago. This is called a hanging or "stuck" execution, and it's more than just a cosmetic problem: by default, according to the official reference for execution variables n8n has no time limit at all, EXECUTIONS_TIMEOUT is set to -1 by default. Without your own configuration, an execution can theoretically run forever, blocking resources, worker slots, and in queue mode entire queues.

This article shows you how to recognize hanging executions, what causes typically lie behind them, and how to set a clean time limit with EXECUTIONS_TIMEOUT and EXECUTIONS_TIMEOUT_MAX that fits your instance. Status: July 2026.

How do you recognize hanging executions?

• In the "Executions" tab, the status stays permanently on "Running" or "Waiting" even though comparable runs are normally finished within seconds or a few minutes.
• The runtime counter keeps growing without any new log entries or node changes becoming visible.
• In queue mode, new executions pile up in the queue because a worker is blocked by the hanging execution and, according to the configuration via N8N_CONCURRENCY_PRODUCTION_LIMIT, is not allowed to start further runs in parallel.
• The server noticeably consumes more memory or CPU without this being explainable by the current load.

A single hanging run seems harmless at first. In practice, however, just a handful of such executions is enough to noticeably slow down an entire n8n instance, especially when several workflows share the same worker pool.

Typical causes of hanging executions

• No timeout set: Without your own EXECUTIONS_TIMEOUT configuration, no automatic limit applies, and a single faulty node can keep the entire run open.
• External calls without their own timeout: An HTTP Request node waiting for a very slow or unresponsive API hangs until the other side responds or n8n itself intervenes.
• Misconfigured Wait nodes: A Wait node waiting for an external event that never occurs keeps the execution permanently in the "Waiting" status.
• Hanging sub-workflows: If your main workflow calls a sub-workflow, the sub-workflow's hang transfers directly to the parent run.
• Problems in queue mode: If the connection between the main process and the worker is disrupted, for example due to unstable Redis access, executions stay in the "Running" state without the worker actually still processing them.

Setting EXECUTIONS_TIMEOUT and EXECUTIONS_TIMEOUT_MAX correctly

For a reliable time limit, according to the configuration guide for workflow timeouts two environment variables are decisive:

• EXECUTIONS_TIMEOUT: Sets the default time limit in seconds that applies to all workflows unless an individual limit has been set. The default is -1, meaning disabled. A value of 3600 limits every run to one hour.
• EXECUTIONS_TIMEOUT_MAX: Defines the absolute upper limit in seconds, which applies even if an individual workflow has set a higher timeout of its own. According to the reference, the default value is 3600 seconds.

Important for understanding how the timeout technically takes effect: if the workflow runs in the main process, according to the documentation a soft timeout occurs, which only takes effect after the currently active node has finished. If the execution instead runs in a separate process, for example in queue mode on a worker, n8n first also attempts a soft abort and then enforces a hard abort. What this means for you: a timeout is not an instant kill switch, but a staggered mechanism that ends running work as cleanly as possible before intervening hard.

Individual workflows can set their own, lower timeout in their workflow settings. However, this is always capped from above by EXECUTIONS_TIMEOUT_MAX, so a single workflow cannot exceed the global limit. This way you keep control over the maximum runtime without every single workflow having to be individually secured.

Cleaning up execution data to keep the database lean

Beyond the pure time limit, it's worth taking a look at the retention of execution data, because an overloaded database also makes diagnosing hanging runs harder. According to the reference, n8n cleans up execution data automatically:

• EXECUTIONS_DATA_PRUNE (default: enabled) controls whether completed executions are automatically deleted at all.
• EXECUTIONS_DATA_MAX_AGE determines after how many hours old executions are considered candidates for deletion; the default value corresponds to 14 days.
• Active executions with the status "new," "running," or "waiting" are explicitly excluded from cleanup, as are executions you have tagged or annotated with ratings.

These safeguards are a double-edged sword: while they prevent a still-running execution from being accidentally deleted, they also mean a truly hanging execution remains permanently in the database as long as no timeout ends it in the regular way. That's exactly why the combination of a sensible EXECUTIONS_TIMEOUT and working data cleanup is important, so hanging runs don't accumulate unnoticed.

Checklist for practice

• First check in the Executions tab which runs have actually been stuck on "Running" or "Waiting" for hours or days.
• Set EXECUTIONS_TIMEOUT to a realistic value for your longest regular workflows, plus a safety buffer.
• Set EXECUTIONS_TIMEOUT_MAX so that even particularly long individual workflows cannot run indefinitely.
• For externally connected nodes, such as HTTP Request or Webhook wait points, check whether it makes sense to add their own timeout there as well.
• In queue mode, also keep an eye on the connection to Redis and the load on your workers, because a hanging worker causes quite different symptoms than a single hanging workflow.

If you run n8n as a digital employee in your company, a cleanly configured timeout is part of the basic setup, just like keeping an eye on concurrency limits and data cleanup. Once you get these settings right, you usually no longer need to worry about hanging executions manually. If you need support with this, or want to make your n8n instance fundamentally more stable, NordFlux supports you with the setup and operation of n8n workflows.

Frequently asked questions

What does the "Waiting" status mean for an n8n execution?

"Waiting" indicates that the execution is waiting at some point in the workflow for an external event, such as a response from a Wait node or a pending webhook call. If this status persists beyond the expected runtime, it points to an event that never occurs, and the execution effectively hangs until a timeout ends it.

What value should I set for EXECUTIONS_TIMEOUT?

There is no single universally correct value; it depends on your longest regular workflows. As a starting point, it helps to measure the normal runtime of your most demanding automation and round it up generously, roughly two to three times. This leaves enough buffer for normal fluctuations while truly hanging runs are still reliably ended.

Does EXECUTIONS_TIMEOUT end an execution immediately?

No, according to the n8n documentation, a soft abort occurs first. In the main process, n8n waits until the currently running node has finished; in separate processes, after a soft attempt, a hard abort is additionally enforced after a short wait. The transition is therefore staggered rather than abrupt.

Can a single workflow have a higher timeout than EXECUTIONS_TIMEOUT_MAX allows?

No. EXECUTIONS_TIMEOUT_MAX defines the absolute upper limit for the entire instance. Even if a workflow has set a higher individual timeout in its own settings, this value is capped by EXECUTIONS_TIMEOUT_MAX, so that no workflow can exceed the global limit.

Are hanging executions automatically deleted from the database?

Not while they are active. n8n explicitly excludes executions with the status "new," "running," or "waiting" from automatic cleanup via EXECUTIONS_DATA_PRUNE. A truly hanging execution therefore remains in place until either a configured timeout ends it or you cancel it manually.