All docs

Enginetrigger.dev primitive

Queues

trigger.dev queues that gate task concurrency. Each Platos environment has at least one queue per task type.

This is a trigger.dev concept that Platos surfaces. Full reference at trigger.dev docs.

Queues

A queue is the engine-layer scheduler's primitive for ordering and concurrency-limiting runs. Each task gets a default queue; you can attach custom queues with explicit concurrency caps.

Platos uses trigger.dev as the durable execution engine. Queues are a trigger.dev concept that Platos surfaces in the dashboard for visibility. The semantics (concurrency limits, master queue routing, per-queue priority) are unchanged from upstream.

In Platos

The Queues page at /orgs/{org}/projects/{project}/env/{env}/queues lists each queue with its current depth, dequeue rate, and concurrency cap. The Concurrency page at /concurrency shows the per-environment cap (the upper bound across every queue).

The most common Platos use of queues is bounding BGO concurrency. A heavy code-runner workload can be capped to N concurrent runs without throttling chat turns: assign the BGO task to its own queue with concurrencyLimit: N, leave chat-side tasks on the default queue.

A "stuck" run is usually a queue with dequeueRate: 0 (worker pool is zero, see Self-hosting) or a queue paused via the dashboard. The status badge surfaces both.

Reference

The full reference for queues lives in the trigger.dev docs:

trigger.dev/docs/v3/queues

  • Runs: every run waits in a queue before execution.
  • Deployments: the deployed task version dictates which queue a run lands in.

Talk to Platos

Powered by the Platos runtime

Powered by Platos →