Yes, I had the same issue last month, but I'm afraid this can come in many shapes and sizes.

If only some executions are queued, and only in some workflows, that might mean your problems are in the nodes or services in that workflow. If you only use a few workflows or nodes, it might give you the impression that it's an n8n or railway problem. Also pay attention if there aren't too many queued executions giving you the illusion none are running (I also fell for that one lol). Additionally, try disabling all workflows, especially webhook triggers, then try canceling a bunch of them in bulk to see if others will run properly. Try a manual trigger.

Here are some other stuff that might be related to your problem. As you provided little detail, see what applies to your case:

“Queued” indefinitely is almost never an n8n or Railway outage; it means you enabled Queue-mode but have no worker online to consume the jobs.

Why it happens • EXECUTIONS_PROCESS=queue (or QUEUE_BULL_REDIS_ENABLED=true) pushes every execution into a Bull queue.
• A separate n8n worker process (N8N_PROCESS_TYPE=worker) must pull and execute the jobs.
• If that worker container is stopped, scaled to 0, or mis-configured, jobs remain forever in the yellow “Queued” state.

Typical Railway causes

1. Only one service was deployed, so Railway starts just the “main” web container—no worker.

2. Worker service exists but is scaled to 0 or crashes on start-up.

3. Redis/Bull variables are missing or wrong, so neither web nor worker reaches the queue.

Fixes

Option A – simplest: disable Queue-mode

1. Remove EXECUTIONS_PROCESS or set it to main.

2. Remove/disable QUEUE_BULL_REDIS_ENABLED and BULL_REDIS vars.

3. Redeploy. The single container will now run UI and executions; workflows start immediately.

Option B – keep Queue-mode (scalable)

1. Keep EXECUTIONS_PROCESS=queue in your “main” service.

2. Add a second Railway service (same repo) and override CMD to run the worker, e.g.
   ["n8n","worker","--tunnel"] or set N8N_PROCESS_TYPE=worker.

3. Ensure both services share the same Postgres and Redis (REDIS_URL or host/port vars).

4. Scale the worker to at least 1 replica.

Verification checklist ✓ Web logs: “Queue mode is enabled”.
✓ Worker logs: “Starting n8n worker … connected to Redis”.
✓ redis-cli -u $REDIS_URL ping → PONG.
✓ Only the web service exposes port 5678; worker exposes none.

Edge cases • Upgrading from very old n8n builds may leave stale rows in execution_entity—clear them or restart gracefully.
• Massive cron bursts can outpace a single worker—add replicas or bump Railway plan limits.

TL;DR: add a worker or disable Queue-mode and your executions will leave “Queued” status and run normally.

Thank you. i changed the execution mode to "regular" and now it's working fine. but I'm still baffled why the problem happened in the first place? the execution mode was "queue" for the past 2 weeks and I didn't had any issue, until yesterday when suddenly all the exections showed "queued" indifinitly

Oh, great!

I have no idea why it happened. Sometimes stuff just break and that's it lol. Be careful with "next" or "beta" versions in production environments btw, so make sure to use the "latest" version. Also just click "redeploy" whenever you get a notification of a new "latest" version so things keep working smoothly.