Workflow is Stuck in "Queued" and "Starting Soon" with Scheduled Trigger

I’m new to n8n, and I’ve created a workflow with a scheduled trigger. The workflow works fine when I test it manually, but when triggered by the schedule, the execution status is stuck in “Queued” and “Starting soon”.

I’ve checked the container logs, and there are no explicit errors, but I do see messages indicating a possible issue with permissions or execution blocks.

Here’s a quick overview of the behavior:

  • Manual execution: Works fine, the workflow runs and completes without issues.
  • Scheduled execution: Remains in the “Queued” state and doesn’t run even after the trigger is fired.

I suspect it might be an issue related to worker availability, system configuration, or execution permission. Can you help me figure out why the scheduled trigger isn’t executing the workflow as expected?

Steps to reproduce:

  1. Created a workflow with a scheduled trigger.
  2. Manually tested the workflow, it executed fine.
  3. Scheduled the workflow and waited for the trigger, but it remains in the “Queued” state.

Please let me know if there’s any log or configuration I should check.

Thank you!

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
  • **n8n version: latest
  • **Database (default: SQLite): postgress
  • **n8n EXECUTIONS_PROCESS setting (default: own, main):
  • **Running n8n via (Docker, npm, n8n cloud, desktop app): Docker compose
  • **Operating system: Ubuntu 22 LTS

hello @vishnu

when you execute a workflow manually, it’s get executed on the main instance. So it seems there is an issue with the workers (maybe main instance can’t connect to them, or they have any issues with the DB/main instance)

I have same issue, any updates on it?

We have the same issues as well.
Does anyone have a fix yet?

Hi @vishnu

Do you have queue mode set at all? If so, how are you running your workers? Have you checked your concurrency? Which frequency is the workflow being triggered? Do you see anything in the logs (set the log level to ‘debug’ as well)

Please share more about your n8n set up and your env vars that you have set to debug this properly.

Thanks!

Same issue here but on any kind of trigger.
The workflows run when executed manually, but when active they pile up as queued.

  • n8n version: 1.81.0
  • Database (default: SQLite): postgreSQL
  • n8n EXECUTIONS_PROCESS setting (default: own, main): Deprecated, using EXECUTIONS_MODE=queue
  • Running n8n via: self-host (node v22.14.0)
  • Operating system: Ubuntu 24.04 LTS

I post some configs as they are in the current state, in case you see something odd.

This is caddyfile (the n8n section only)

n8n.xxxxx.xx {
    # Suggested for Telegram Trigger
    handle /webhook/* {
        reverse_proxy localhost:5678 {
            header_up Host {host}
            header_up X-Forwarded-Proto https
        }
    }
    reverse_proxy localhost:5678 {
        header_up Host {host}
        header_up X-Forwarded-Proto https
    }
}

main.env (only the related envs):

N8N_ENCRYPTION_KEY=xxxxx
NODE_ENV=production
EXECUTIONS_MODE=queue
N8N_ENDPOINTS_WORKFLOW_ENABLED=true
N8N_ENDPOINT_WEBHOOK=webhook
N8N_ENDPOINT_WEBHOOK_TEST=webhook-test
N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true

# Trying now explicitly with the IP
QUEUE_BULL_REDIS_HOST=127.0.0.1
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_DB=1
QUEUE_BULL_PREFIX=n8n-queue-prod
QUEUE_HEALTH_CHECK_ACTIVE=true

worker.env (main, worker and webhook also include postgres envs):

N8N_ENCRYPTION_KEY=xxxxx
NODE_ENV=production
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_CONCURRENCY=5
QUEUE_BULL_PREFIX=n8n-queue-prod
QUEUE_BULL_REDIS_HOST=127.0.0.1
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_DB=1

webhook.env

N8N_ENCRYPTION_KEY=xxxxx
NODE_ENV=production
EXECUTIONS_MODE=queue
QUEUE_BULL_PREFIX=n8n-queue-prod
QUEUE_BULL_REDIS_HOST=127.0.0.1
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_DB=1

redis.conf (on redis_version:7.0.15)

bind 127.0.0.1 -::1
protected-mode yes
port 6379

pm2 processes:

│ 1  │ n8n-main    │ fork     │ 0    │ online    │ 0%  │ 285.1mb  │
│ 3  │ n8n-webhook │ cluster  │ 5904 │ online    │ 0%  │ 159.5mb  │
│ 2  │ n8n-worker  │ cluster  │ 5911 │ online    │ 0%  │ 160.0mb
1 Like

Yeah I have the same issue, thank you Dogway for your detailed reply, but as i see here no one adressed our issue(

I created a new topic here, with improvements on my setup but still no dice.