#Dev runs stuck in DEQUEUED - Hobby plan, SDK 4.4.3

1 messages · Page 1 of 1 (latest)

fierce harness
#

Dev runs stuck in DEQUEUED - Hobby plan, SDK 4.4.3

Project ref: proj_ggeilfopgbgodymfomff
SDK/CLI: 4.4.3 (latest), Node 24, macOS

Problem: When I batch-trigger 5+ angle-generate tasks in dev, only ~2-4 actually execute. The rest get stuck in DEQUEUED status forever (zero attempts, 0ms duration). They never transition to
EXECUTING or retry. I have to manually cancel them.

What I've tried:

  • Fresh npx trigger.dev dev restart (clean .trigger/ dir)
  • Confirmed no zombie trigger-dev-run-worker processes (re: #2909)
  • Updated all packages to 4.4.3 (latest on npm)
  • Used --max-concurrent-runs 25 CLI flag - improved from ~2 to ~4 concurrent, but still not 5/5
  • Verified no other dev runs are consuming slots

What I found in the CLI source:
// node_modules/trigger.dev/dist/esm/dev/devSupervisor.js
const maxConcurrentRuns = Math.min(
this.config.maxConcurrentRuns, // from server /dev/config endpoint
this.options.args.maxConcurrentRuns ?? this.config.maxConcurrentRuns
);
this.runLimiter = pLimit(maxConcurrentRuns);

The CLI flag can never exceed what the server config returns. My Hobby plan pricing page says 25 dev concurrent runs, but the server config appears to be sending a lower number.

Question: What maxConcurrentRuns value does the /dev/config endpoint return for my project? And is there a way to increase it to match the 25 advertised on the pricing page?

Example stuck run: run_cmn8qober871e0aod1e0poung (dequeued Mar 27, sat there 20+ min, zero attempts)

pseudo pythonBOT
#

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

#

Based on the knowledge sources available, here's what I can confirm and where the information runs out:

What the Docs Say About Dev Concurrency

The Hobby plan supports 25 concurrent runs overall, but the dev-specific concurrency is controlled separately. For self-hosted instances, the relevant setting is DEV_MAX_CONCURRENT_RUNS (default: 25) on the webapp. [Webapp env vars]

Your observation about the CLI capping at the server-returned value is consistent with how the system works — the --max-concurrent-runs CLI flag cannot exceed what the server's /dev/config endpoint returns.

What the Docs Don't Cover

The knowledge sources do not contain information about:

  • The specific value the /dev/config endpoint returns for Hobby plan projects on Trigger.dev Cloud
  • Why your project's server config might be returning a lower number than the advertised 25
  • Internal details of how the Hobby plan's dev concurrency limit is configured on the cloud side

What You Can Try

  1. Check the CLI dev options — the --max-concurrent-runs flag is a valid option, but as you've found, it's bounded by the server config. [CLI dev command]

  2. Check for stuck/blocking runs — runs in DEQUEUED state count against concurrency limits. If any runs are stuck in EXECUTING or DEQUEUED, they may be blocking new executions. [Troubleshooting]

#
  1. Use processKeepAlive — this won't fix the concurrency cap, but can reduce process startup overhead in dev:
    export default defineConfig({
  project: "<project ref>",
  processKeepAlive: {
    enabled: true,
    maxExecutionsPerProcess: 50,
    devMaxPoolSize: 25,
  },
});
    [Process keep alive]

Recommended Next Step

Since this involves your specific project's server-side configuration (proj_ggeilfopgbgodymfomff) and the value being returned by the /dev/config endpoint, you'll need to contact the Trigger.dev team directly — either via email or Discord — to verify what concurrency value is configured for your project and have it corrected to match the advertised 25 dev concurrent runs for the Hobby plan.

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

#

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

fervent fjord
#

i checked the db and your dev environment is correctly set at 25. maybe this is due to the other tasks taking up some concurrency in your environment?

fierce harness
#

Hey, no other tasks in the queue, it happens even with 1 task, even when i replay it sometimes, If I use the MCP with the same payload it works.

somber cargo
#

Hello, I experience the same issue, every task after the first one goes to the dequeued, any solution?

#

@fervent fjord