#Managed worker tasks stuck in "Queued" indefinitely — never executed

1 messages · Page 1 of 1 (latest)

still lantern
#

Hey everyone, running into an issue where my tasks stay in "Queued" forever and never get picked up by a worker.

Setup:

  • Trigger.dev v4.4.1 (SDK + CLI)
  • Production environment, Managed workers, us-east region
  • Node.js v21.7.3 runtime
  • 1 task deployed, status shows "Deployed" and "Current"

What I've tried:

  • Set all env vars in the Trigger.dev dashboard
  • Cancelled stale runs and triggered fresh ones
  • Tested directly from the Test dashboard with a manual payload
  • Redeployed multiple times
  • Billing is active, status.trigger.dev shows no incidents

Symptom: Every run — including test runs from the dashboard — immediately enters "Queued" and sits there indefinitely (5+ minutes, no progress, no errors shown).

Is this a known issue? Any ideas what could cause workers to never pick up queued tasks in production?

old coralBOT
#

Hi @still lantern. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

The knowledge sources don’t describe a specific “managed workers never dequeue runs” incident, so I can’t confirm this as a known issue. I can only point to the documented reasons runs may stay queued and how to debug them.

From the docs, runs can remain in QUEUED when:

  • You’re at or near your environment or queue concurrency limits, so new runs wait in the queue. [Limits; Concurrency]
  • A queue has a low concurrencyLimit and existing runs are still EXECUTING/DEQUEUED. [Concurrency]
  • There are stuck runs in EXECUTING that never release concurrency (e.g. stalled or blocking the event loop). [Runtime issues; Task stalled]

The troubleshooting guide suggests for “Runs waiting in queue due to concurrency limits”: [Runtime issues]

  1. In the dashboard, check:

    • How many runs are EXECUTING or DEQUEUED (these consume concurrency).
    • Whether any runs are stuck in EXECUTING or showing TASK_RUN_STALLED_EXECUTING.

  2. Verify your queue settings:

    • If your task defines queue: { concurrencyLimit: 1 } or uses a shared queue, confirm you don’t have a long‑running or stuck run on that queue. [Concurrency]

  3. Check environment concurrency:

    • Compare your plan’s concurrency limit with how many runs are currently executing. [Limits]
#
  1. Confirm runs aren’t in another initial state:
    • WAITING_FOR_DEPLOY, DELAYED, or EXPIRED can look similar at a glance; check the run status and timestamps in the run details. [Runs; Run object; Trigger options]

Because your description is “every run, including test runs, sits in QUEUED indefinitely” and the docs don’t list any other cause beyond concurrency/queue issues, if you’ve verified:

  • No runs are EXECUTING/DEQUEUED,
  • No restrictive concurrencyLimit on the task/queue,
  • No delay/ttl options being set,

then the knowledge sources don’t provide further documented causes or fixes. In that case, the docs implicitly point you to general troubleshooting and support rather than a self‑service fix. [Runtime issues]

So, based on the docs alone, the next step would be:

  • Double‑check concurrency and queue settings as above.
  • If everything looks normal but runs still never leave QUEUED, this falls outside what the docs cover, and you’d need to contact Trigger.dev support (email/Discord) for a backend investigation.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@still lantern Kapa.ai is still learning and improving, please let me know how I did by reacting below.

still lantern
#

Thanks. I've verified:

  • No runs are currently EXECUTING or DEQUEUED
  • The task has no queue or concurrencyLimit set
  • No delay or ttl options being passed when triggering
  • Run status is definitely QUEUED (not WAITING_FOR_DEPLOY, DELAYED, or EXPIRED)

This is a brand new project/deployment with zero prior successful runs. The very first test run from the dashboard has never left QUEUED. What's the concurrency limit on the
free/hobby plan for managed workers in production, and could a brand new account have workers disabled by default?

#

@old coral Thanks. I've verified:

  • No runs are currently EXECUTING or DEQUEUED
  • The task has no queue or concurrencyLimit set
  • No delay or ttl options being passed when triggering
  • Run status is definitely QUEUED (not WAITING_FOR_DEPLOY, DELAYED, or EXPIRED)

This is a brand new project/deployment with zero prior successful runs. The very first test run from the dashboard has never left QUEUED. What's the concurrency limit on the
free/hobby plan for managed workers in production, and could a brand new account have workers disabled by default?

old coralBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

The docs do list the relevant concurrency limits, and they don’t mention any “workers disabled by default” behavior for new projects or accounts.

For environment concurrency limits (applies to managed workers too): [Limits]

  • Free: 10 concurrent runs
  • Hobby: 25 concurrent runs
  • Pro: 100+ concurrent runs (can buy more)

These are per environment; a single queue can’t exceed the base environment limit, but you’re not defining any custom queue or concurrencyLimit, so you’re just using the default unbounded-per-task behavior, capped only by the environment limit. [Concurrency & queues]

The docs also explicitly say that only EXECUTING/DEQUEUED runs count toward concurrency; QUEUED runs don’t consume slots. [Concurrency & queues] So with:

  • 0 EXECUTING / DEQUEUED runs
  • No custom queue limits

you should not be blocked by concurrency.

Regarding your second question: the knowledge sources do not state that new accounts or new projects have managed workers disabled by default, nor do they describe any “activation” step for workers. They just describe limits and behavior once runs are being processed. [Limits; Runs]

Given that:

  • You’re on Free/Hobby (well within the documented concurrency limits),
  • No runs are executing,
  • Tasks are deployed and runs are stuck in QUEUED,

this specific “brand new project, first run never leaves QUEUED” situation is not covered in the docs. The knowledge sources don’t provide another documented cause or self-service fix beyond the concurrency/queue checks you’ve already done.

#

At this point, based on the docs alone, the next step is to contact Trigger.dev directly (email or Discord) so they can inspect your project/region and worker allocation on their side, since that behavior isn’t explained in the public documentation.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@still lantern Kapa.ai is still learning and improving, please let me know how I did by reacting below.

still lantern
#

Confirmed — 0 executing/dequeued runs, no custom queue or concurrency limits, within plan limits. Bot has confirmed this is outside documented behavior.

This is a brand new project with zero prior successful runs — the very first run ever triggered has never left QUEUED. Has anyone else seen this with a new project on
managed workers in us-east? Could this be a regional worker availability issue or something that needs a Trigger.dev team member to look at on the backend?

dusty kiln
#

@still lantern Could you share a link to the runs page in your dashboard?

This is definitely not normal and we are processing millions of runs each hour

still lantern
dusty kiln
#

DId you set ⁨concurrencyLimit: 0⁩ in your code?

#

Or press the pause button in the UI, or use ⁨queues.pause()⁩?

#

You can unpause it from that link above but check you don't have ⁨concurrencyLimit: 0⁩ in your code