CircleCI workflow concurrency setting and unexpected queued latency

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?