n8n Queue Mode Incorrect Queue Name Error

Who this is for: Developers and DevOps engineers running n8n in production with queue‑mode enabled (Redis, RabbitMQ, or BullMQ). We cover this in detail in the n8n Queue Mode Errors Guide.

---

Quick Diagnosis

The “Incorrect queue name” error appears when N8N_QUEUE_NAME (or the queue name embedded in the broker URL) does not match any queue that the broker is configured to accept. Jobs are never dispatched and the UI appears stalled.

One‑line verification (Shell)

# Show the queue name n8n is using
echo "$N8N_QUEUE_NAME"

List queues on the broker

Redis

# Show BullMQ keys that contain “n8n”
redis-cli KEYS "bull:*" | grep "n8n"

RabbitMQ

# Requires rabbitmqadmin
rabbitmqadmin list queues name | grep n8n

If the names differ, update one side so they match, then restart n8n.

# Example – set the correct name in .env or Docker compose
export N8N_QUEUE_NAME=n8n_default

1. Why n8n Throws “Incorrect Queue Name” ?

If you encounter any n8n queue mode incorrect queue type resolve them before continuing with the setup.

Symptom	Root Cause	Typical Trigger
Error: Incorrect queue name in logs	Queue name supplied to the broker client does not exist or is misspelled.	Manual edit of N8N_QUEUE_NAME Switching brokers without updating the name Env‑var overrides in Docker/K8s
Jobs stay in waiting state	Broker rejects the connection because it cannot bind to the requested queue.	Same as above; also a stale BullMQ prefix.

EEFA note – In production, a mismatched queue silently drops tasks, causing data loss. Verify the queue exists before scaling workers.

2. Locate the Misnamed Queue in Your Deployment

2.1. Docker‑Compose / Docker‑Swarm

Check the environment variable inside the container

docker exec n8n printenv N8N_QUEUE_NAME

Excerpt from a typical docker‑compose.yml

services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_QUEUE_MODE=queue
      - N8N_QUEUE_NAME=${N8N_QUEUE_NAME:-n8n_default}
      - N8N_QUEUE_BROKER=redis://redis:6379

2.2. Kubernetes (Helm chart)

Inspect the pod’s environment

kubectl exec -it $(kubectl get pod -l app=n8n -o jsonpath='{.items[0].metadata.name}') \
  -- printenv N8N_QUEUE_NAME

Relevant snippet from values.yaml

env:
  - name: N8N_QUEUE_MODE
    value: "queue"
  - name: N8N_QUEUE_NAME
    value: "n8n_default"
  - name: N8N_QUEUE_BROKER
    value: "redis://redis-master:6379"

2.3. Stand‑alone binary / systemd

Show the environment line from the service file

systemctl show n8n --property=Environment

Excerpt from /etc/systemd/system/n8n.service

[Service]
Environment="N8N_QUEUE_NAME=n8n_default"

3. Verify the Queue Exists on the Broker

3.1. Redis (BullMQ) – list keys

redis-cli KEYS "bull:*" | grep "n8n"

Expected key pattern	Example
bull:{queueName}:id	bull:n8n_default:id

If the key is missing, the queue has never been created. If you encounter any n8n queue mode incorrect priority resolve them before continuing with the setup.

3.2. RabbitMQ – list queues

rabbitmqadmin list queues name | grep n8n

Expected queue name	Example
n8n_default	n8n_default

3.3. Create a missing BullMQ queue (production‑safe)

Run this one‑off from an admin container or maintenance pod.

// create-queue.js – create the queue if it does not exist
const { Queue } = require('bullmq');
const queue = new Queue('n8n_default', {
  connection: { host: 'redis', port: 6379 },
});
queue.waitUntilReady().then(() => console.log('Queue created'));

node create-queue.js

EEFA warning – Do **not** execute queue‑creation code on a live worker node; use a temporary admin pod to avoid race conditions.

4. Align n8n’s Queue Name with the Broker

1. Pick the authoritative source – either the broker’s existing queue name or the name you intend n8n to use.
2. Update N8N_QUEUE_NAME to match exactly (case‑sensitive).
3. Restart the n8n service (Docker, K8s, or systemd).

4.1. Docker‑Compose fix

services:
  n8n:
    environment:
      - N8N_QUEUE_NAME=n8n_default   # ← corrected

docker-compose up -d --force-recreate n8n

4.2. Kubernetes patch

kubectl set env deployment/n8n N8N_QUEUE_NAME=n8n_default
kubectl rollout restart deployment/n8n

4.3. Systemd reload

sudo systemctl edit n8n   # add/modify Environment line if needed
sudo systemctl daemon-reload
sudo systemctl restart n8n

5. Validate the Fix

1. Tail the logs for the error – no output means the error is cleared.

# Docker
docker logs -f n8n | grep "Incorrect queue name"
# Kubernetes
kubectl logs -f $(kubectl get pod -l app=n8n -o jsonpath='{.items[0].metadata.name}')

2. Trigger a simple workflow that uses a queue‑enabled node (e.g., “Execute Workflow” with a delay).
3. Inspect the broker to confirm the job appears.

Redis

redis-cli LLEN bull:n8n_default:wait   # should be >0

RabbitMQ

rabbitmqadmin list queues name messages_ready | grep n8n_default

If jobs show up and the UI updates, the issue is resolved.

6. Prevent Future Misnaming – Checklist

Action	Why It Matters
Lock N8N_QUEUE_NAME in version‑controlled config (docker‑compose, Helm values, etc.)	Guarantees consistency across environments.
Add a CI lint step that validates N8N_QUEUE_NAME against an allow‑list	Catches typos before deployment.
Enable the health‑check endpoint (/healthz) and monitor for queue‑related errors	Early detection before jobs stall.
Document broker‑queue naming conventions in your run‑book	Reduces human error during scaling or migrations.
Use a dedicated namespace/prefix (e.g., n8n_prod) for production queues	Avoids cross‑environment collisions.

Conclusion

The “Incorrect queue name” error is caused by a mismatch between N8N_QUEUE_NAME and the actual queue configured in your broker. By:

1. Verifying the environment variable,
2. Listing existing queues on Redis or RabbitMQ,
3. Creating the missing queue if necessary, and
4. Aligning the variable with the broker’s name,

you restore job dispatching and prevent silent data loss. Lock the queue name in source‑controlled configuration, add CI validation, and monitor health endpoints to keep production deployments reliable.