Self-Hosted n8n Cluster on Railway: Worker Not Dequeuing Jobs (Webhook Triggers Stuck in Queue)

Questions
1

Hello n8n Community,

I’m running into a persistent issue with my self-hosted n8n cluster on Railway and would greatly appreciate any insights or suggestions.

Setup:

  • Platform: Railway

  • n8n Version: 1.116.1

  • Mode: Clustered Queue Mode

  • Services: n8n-master, n8n-worker, n8n-whp, n8n-redis, n8n-pg (PostgreSQL)

Problem:

Workflows triggered via Webhook immediately get stuck in the “Queued” status and never execute. They eventually time out.

However, workflows triggered manually (e.g., using the Manual Trigger node) execute successfully and instantly.

This occurs even with the simplest possible webhook workflow: Webhook → Respond to Webhook.

Key Findings & Logs:

  • The n8n-whp service logs correctly show “Enqueued execution (job XX)” when a webhook request is received.

  • The n8n-worker service logs show NO activity related to picking up or processing these jobs. Crucially, the worker’s startup logs show no attempt to connect to Redis or initialize the BullMQ queue system.

  • The n8n-redis service logs are clean and show normal operation (background saves, etc.) with no errors.

  • The n8n-master logs show no relevant errors during webhook triggering.

Troubleshooting Steps Already Taken:

I have meticulously checked and confirmed the following configurations based on n8n docs and Railway support suggestions:

  1. Resources: Verified sufficient CPU/Memory on master (1vCPU/2GB) and worker (4vCPU/8GB). Metrics do not show maxing out.

  2. Execution Mode: Confirmed EXECUTIONS_MODE=queue is set on master, worker, and whp.

  3. Worker Process Config:

    • Confirmed EXECUTIONS_PROCESS=main is set on worker.

    • Added N8N_PROCESS_TYPE=worker specifically to the worker.

  4. Redis Connection:

    • Triple-checked QUEUE_BULL_REDIS_HOST, PORT, PASSWORD, USERNAME on master, worker, whp. Confirmed they exactly match the n8n-redis service details and use the internal Railway hostname.

    • Confirmed QUEUE_BULL_REDIS_DUALSTACK=true is set on master, worker, whp.

  5. Queue Name: Explicitly set QUEUE_BULL_NAME=n8n_queue on master, worker, whp.

  6. Master Config: Confirmed N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true is set on master.

  7. Redeployments: All services have been redeployed multiple times after configuration changes.

Conclusion & Question:

Despite all configurations appearing correct for queue mode, the n8n-worker is simply not attempting to connect to Redis to dequeue jobs when triggered via webhook. It seems like an initialization issue specific to the worker in queue mode within the Railway environment.

Has anyone encountered a similar issue with n8n clusters on Railway where the worker fails to initialize its queue connection? Are there any other environment variables or specific Railway settings I might be missing?

Any help or pointers would be greatly appreciated!

Thank you.