n8n Workflow Stuck in Running State: Complete Fix Guide

April 22, 2026 · Editorial Team · 5 min read · n8n troubleshooting error-fix

You're running n8n 1.65 on a VPS or a Kubernetes cluster. A workflow that processes Typeform submissions, runs them through an OpenAI node, and writes results to a Postgres table. It worked for three days, then one execution got stuck. The workflow status shows "Running" in the executions list, the spinner keeps spinning, and no data lands in Postgres. You restart the execution manually and it gets stuck again. Other workflows on the same instance are fine. This is one of the more frustrating bugs in self-hosted n8n, partly because the UI gives you almost nothing to work with. Here's a systematic way to find and fix it.

What this error actually means

When an n8n execution is stuck in "running," it usually means the process that was handling that execution died or lost connectivity without properly closing the execution record. n8n stores execution state in its backing database (SQLite by default on simple installs, Postgres or MySQL on production setups). If the worker process crashes, gets OOM-killed, or loses the database connection mid-execution, the execution row stays marked as running forever because nothing cleaned it up. The workflow appears stuck from the UI because n8n is reading that running status from the database and showing it faithfully.

Quick fix (when you need it working in 60 seconds)

SSH into your n8n server and run pm2 status or docker ps to check if the n8n process is actually alive.
If the process is running, check logs for the last 100 lines: pm2 logs n8n --lines 100 or docker logs n8n --tail 100. Look for ENOMEM, ECONNRESET, or Error: Connection lost messages.
Manually mark the stuck execution as failed. In a Postgres-backed instance run: UPDATE execution_entity SET status = 'error', "stoppedAt" = NOW() WHERE status = 'running' AND id = <your_execution_id>;
For SQLite: UPDATE execution_entity SET status = 'error', stoppedAt = datetime('now') WHERE status = 'running';
Restart the n8n process and re-trigger the workflow from scratch.

Why this happens

Self-hosted n8n has several distinct failure modes that all produce the same "stuck running" symptom.

The most common cause on small VPS instances is an out-of-memory kill. n8n's Node.js process grows memory usage as executions accumulate in-memory state. If the VPS has 1-2 GB RAM and you're running several concurrent workflows with large payloads (Typeform responses with attachments, large JSON blobs from APIs), the kernel will OOM-kill the process. The database doesn't get updated, so all in-flight executions stay marked as running.

Another frequent cause is database connection pooling issues. The default n8n configuration connects to Postgres with a small pool. Under moderate load, connections queue up. If the database goes briefly unreachable (a Postgres restart, a network blip on a managed DB like RDS or Supabase), any execution that's mid-write will hang indefinitely waiting for a connection that never returns.

The OpenAI and Anthropic nodes in n8n don't have configurable timeout values in the UI as of 1.65. If the model API is slow or returns an unexpected response format, the HTTP request inside the node can sit open for minutes with no progress. n8n's default HTTP timeout settings are generous enough that this can look like a hang rather than a clean error.

Finally, webhook-triggered workflows can get stuck if the webhook source sends a second request while the first execution is still running. Depending on your workflow's "Respond to Webhook" node placement, the second request might acquire a lock that blocks both executions from completing.

Permanent fix

Set EXECUTIONS_TIMEOUT=300 in your n8n environment variables. This forces any execution running longer than 300 seconds (5 minutes) to be automatically terminated and marked as failed rather than spinning indefinitely.
Set EXECUTIONS_TIMEOUT_MAX=600 as a hard ceiling. Both variables work together: EXECUTIONS_TIMEOUT is the default, EXECUTIONS_TIMEOUT_MAX is the upper bound that can't be overridden per-workflow.
Increase your VPS or container's memory allocation. n8n recommends at least 2 GB for a production instance handling more than 5 concurrent workflows. If you can't add RAM, reduce EXECUTIONS_DATA_MAX_AGE to prune old execution records more aggressively, which keeps the database smaller.
Configure Postgres connection pool settings explicitly: DB_POSTGRESDB_POOL_SIZE=10 and DB_POSTGRESDB_POOL_IDLE_TIMEOUT=30000. The idle timeout ensures connections aren't held open forever during database blips.
Add a health check endpoint. n8n exposes /healthz on its port. Configure your process manager or load balancer to hit this endpoint every 30 seconds. If it returns non-200, trigger an automatic restart and send you an alert.
For webhook workflows, enable the "Wait for webhook response before continuing" option in your workflow settings, or restructure so the "Respond to Webhook" node fires early in the flow before the slow AI node.
Switch from the default SQLite backing to Postgres if you haven't already. SQLite under concurrent load produces write locks that cause executions to stall. Postgres handles concurrent writes correctly.
Pin your n8n Docker image to a specific version tag (e.g., n8nio/n8n:1.65.2) instead of latest. Unexpected version bumps have introduced execution-handling regressions in the past, and being on a known-good version makes debugging much easier.

Prevention

Monitor your n8n instance's memory usage continuously. A simple cron job that curls the n8n healthz endpoint and alerts you when the process restarts will catch OOM kills before they become a pattern. Set up a WEBHOOK_URL in your monitoring tool to notify your Slack or Teams channel when n8n goes down.

Review execution data retention settings every month. n8n stores the full input/output data for every execution by default. On an active instance, this can fill gigabytes of disk space and slow database queries, which contributes to the hanging behavior. Set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none for high-volume workflows where you don't need to audit successful runs.

Test your workflows with the largest realistic payloads before going to production. n8n's "Execute Workflow" debug runner lets you paste a sample input. Use the biggest JSON blob you might realistically receive and watch memory usage in your server's dashboard while the test runs.

When the fix doesn't work

If executions keep getting stuck even after setting EXECUTIONS_TIMEOUT, check whether the timeout is actually being picked up. Run docker exec n8n env | grep EXECUTIONS_TIMEOUT to confirm the variable is in the container's environment. Environment variable injection issues are common when using Docker Compose files where the env_file reference path is wrong.

If you're on n8n Cloud rather than self-hosted, you don't control execution timeouts directly. Contact n8n Cloud support via their in-app chat. Include the workflow ID and the stuck execution ID from the URL when viewing that execution.

For stuck executions that can't be cleared through the database update method (perhaps because you don't have direct database access), n8n's CLI includes a manual cleanup command: n8n execution:prune --cleanDatabase. Run this with the n8n process stopped to reset all stuck executions.