{"id":2953,"date":"2026-11-05T09:52:15","date_gmt":"2026-11-05T09:52:15","guid":{"rendered":"https:\/\/hostry.com\/blog\/?p=2953"},"modified":"2026-11-05T09:52:17","modified_gmt":"2026-11-05T09:52:17","slug":"n8n-queue-mode-workers-not-picking-up-jobs","status":"publish","type":"post","link":"https:\/\/hostry.com\/blog\/n8n-queue-mode-workers-not-picking-up-jobs\/","title":{"rendered":"n8n Queue Mode Workers Not Picking Up Jobs: Fixes and Sizing on a VPS"},"content":{"rendered":"\n
\"n8n<\/figure>\n\n\n\n
n8n queue mode workers not picking up jobs, and executions stuck in Queued, usually mean that main and the workers see a different Redis, encryption key or database. Run the six checks below in order, from queue mode on main through worker health, Redis, key and Postgres; the last one, concurrency, explains jobs that start but run one at a time.<\/strong><\/em><\/pre>\n\n\n\n
The commands assume Docker Compose on a Hostry KVM VPS<\/a><\/strong> or any server where you have root, with Postgres and Redis on the Compose network only, and n8n 2.46.6, the stable<\/span> tag on November 5, 2026.<\/p>\n\n\n\n
Workers not picking up jobs: checks in order<\/h2>\n\n\n\n
Run everything next to compose.yaml<\/span>; service names match the file further down, and log lines are quoted from the 2.46.6 source. This helper prints a container’s environment from the host, so no tools in the image are needed:<\/p>\n\n\n\n
envof() { docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' \"$(docker compose ps -q \"$1\")\"; }<\/code><\/pre>\n\n\n\n
1. Confirm that main enqueues the execution<\/strong><\/p>\n\n\n\n
Test with a production execution, such as a webhook call. In 2.x, editor runs stay on main unless OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true<\/span>, so a silent worker during a manual test is normal. Then look at main:<\/p>\n\n\n\n
envof n8n | grep '^EXECUTIONS_MODE'\ndocker compose logs n8n | grep 'Enqueued execution'<\/code><\/pre>\n\n\n\n
In queue mode, main logs Enqueued execution <id> (job <id>)<\/code> for every production run it hands over. If the variable is missing or the log never shows an Enqueued line, main is executing workflows in its own process and nothing reaches Redis. The worker<\/span> command forces its own process into queue mode, so main’s setting is the one that decides; keep it on both, as the docs ask.<\/p>\n\n\n\n
2. Check that the worker is running and ready<\/strong><\/p>\n\n\n\n
docker compose ps\ndocker compose logs --tail=40 n8n-worker-1\ndocker compose exec n8n-worker-1 node -e \"fetch('http:\/\/127.0.0.1:5678\/healthz\/readiness').then(r=>console.log(r.status))\"<\/code><\/pre>\n\n\n\n
A worker that started cleanly logs n8n worker is now ready<\/code>, followed by its Version, Concurrency, Pool and Queue; the queue should read jobs<\/span>. The readiness call answers 200 only when both the database and Redis connections are up, and 503 otherwise. It needs QUEUE_HEALTH_CHECK_ACTIVE=true<\/span>; without it, and with metrics off, the worker opens no HTTP server at all.<\/p>\n\n\n\n
If docker compose ps<\/span> shows the worker restarting, the end of its log names the reason. A Redis problem shows as Unable to connect to Redis after trying to connect for 10s<\/code> and then Exiting process due to Redis connection error<\/code>; the 10 seconds are QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD<\/span> (10000 ms). A worker with no key at all refuses to start with Failed to start worker because of missing encryption key.<\/code><\/p>\n\n\n\n
3. Compare Redis and database settings across containers<\/strong><\/p>\n\n\n\n
QUEUE_BULL_REDIS_HOST<\/span> defaults to localhost<\/span>, and inside a container that means the container itself. A worker without the variable reaches no Redis and restarts as in check 2. The quieter failure is a worker on the right server with a different QUEUE_BULL_REDIS_DB<\/span> (default 0) or QUEUE_BULL_PREFIX<\/span> (default bull<\/span> in the source). It starts cleanly and waits on a queue nobody writes to, without an error.<\/p>\n\n\n\n
for s in n8n n8n-worker-1; do\n  printf '%-14s ' \"$s\"\n  envof \"$s\" | grep -E '^(EXECUTIONS_MODE|QUEUE_BULL_|DB_|N8N_ENCRYPTION_KEY)' | sort | sha256sum\ndone\ndocker compose exec redis redis-cli LLEN bull:jobs:wait\ndocker compose exec redis redis-cli LLEN bull:jobs:active<\/code><\/pre>\n\n\n\n
Matching hashes mean main and worker agree, with no secret printed. Otherwise, compare the names alone with envof n8n-worker-1 | grep -E ‘^(QUEUE_BULL_|DB_)’ | cut -d= -f1<\/span>, then read those values on both sides in your own terminal, such as envof n8n | grep ‘^QUEUE_BULL_REDIS_DB’<\/span>. Fix .env<\/span> and run docker compose up -d<\/span>, which per the Docker docs recreates containers whose configuration changed, keeping volumes. Then repeat check 1.<\/p>\n\n\n\n
A wait<\/span> count that keeps growing while active<\/span> stays at 0 means jobs reach Redis and no worker consumes them from that database and prefix.<\/p>\n\n\n\n
4. Use one N8N_ENCRYPTION_KEY everywhere<\/strong><\/p>\n\n\n\n
When the worker’s key differs from main’s, jobs are picked up and then fail with Credentials could not be decrypted. The likely reason is that a different \"encryptionKey\" was used to encrypt the data.<\/code> A key also lives in \/home\/node\/.n8n\/config<\/span>, where main stores a random one on first start if N8N_ENCRYPTION_KEY<\/span> was never set. Adding the variable later with a fresh value makes n8n stop with Mismatching encryption keys<\/code>. Read the existing key out instead:<\/p>\n\n\n\n
docker compose exec n8n node -e \"console.log(JSON.parse(require('fs').readFileSync('\/home\/node\/.n8n\/config','utf8')).encryptionKey)\"<\/code><\/pre>\n\n\n\n
Put that value in .env<\/span> for main and every worker, and store a copy away from the server; a database restored without it has every credential unreadable.<\/p>\n\n\n\n
5. Point main and workers at the same Postgres database<\/strong><\/p>\n\n\n\n
A worker without DB_TYPE=postgresdb<\/span> falls back to a private SQLite file, which the docs do not support for distributed setups. At startup it warns Scaling mode is not officially supported with sqlite. Please use PostgreSQL instead.<\/code> Later it dequeues jobs it cannot find and logs Worker failed to find data for execution <id> (job <id>)<\/code>. A different DB_POSTGRESDB_DATABASE<\/span> or DB_POSTGRESDB_SCHEMA<\/span> on the worker ends the same way; the hash loop catches both.<\/p>\n\n\n\n