CircleCI workflow concurrency setting and unexpected queued latency

Question

When a workflow defines a concurrency limit, CircleCI queues any additional trigger that exceeds that limit, and the queued runs remain in a queued state until a slot becomes free.

The goal is to determine whether this queuing introduces measurable latency only under concurrent request loads and to clarify any undocumented limits or timeouts that govern the queue.

CircleCI’s documentation does not specify a maximum queue length, a timeout for queued jobs, or whether the API returns a back‑pressure signal when the queue is full, leaving the behavior ambiguous during sustained high traffic.

What is the maximum number of workflow runs that can be queued before CircleCI applies back‑pressure or rejects new triggers? Is there a configurable timeout after which queued workflows are automatically cancelled? Does the queued state affect downstream job scheduling or resource allocation beyond delaying the start time?

Muntasir · Answer

AnswerCircleCI does not impose a documented maximum queue length or a configurable timeout for workflows that exceed a concurrency limit. Additional triggers are placed in a queued state and remain there until a concurrency slot becomes free. While queued, no containers or credits are allocated and downstream jobs are not scheduled; the queued state only delays the start time of the workflow.
Confirmed facts
There is no published upper bound on the number of queued workflow runs; the platform will keep accepting new triggers until system‑wide limits (e.g., API rate limits) are reached.No timeout or automatic cancellation exists for queued runs; they stay queued indefinitely until they can start or are manually cancelled.Queued runs consume zero credits and do not allocate any executors; therefore they do not affect resource allocation or the scheduling of other workflows beyond the delay they introduce.
Verification steps
Create a workflow with a low concurrency setting, e.g., concurrency: 1.Trigger the workflow many times in rapid succession via the CircleCI API or UI (e.g., a loop that POSTs to /project/:vcs-type/:org/:repo/pipeline).Use the API endpoint /project/:vcs-type/:org/:repo/workflow to list workflow runs and observe the queued count increase without receiving HTTP 429 or other rejection responses.Check the CircleCI usage dashboard; credits should remain unchanged while runs are queued and only increase when a run leaves the queued state and starts executing.Leave a batch of queued runs untouched for several hours and confirm they remain queued rather than being auto‑cancelled.

CircleCI workflow concurrency setting and unexpected queued latency

1 answer

Answer

Confirmed facts

Verification steps

Your perspective belongs here.

0 question comments