A deployment platform's build queue is forty minutes deep after a popular framework release. Before adding capacity, what should be examined in the queue itself?

What to examine first

• Superseded work. If three commits land on a branch while the first build is queued, usually only the last matters. Cancelling superseded builds is frequently the single largest capacity saving during a burst and is almost free to implement.
• Duplicates. The same commit built twice concurrently is common with retries and duplicate webhook deliveries. Collapsing them by content key is free capacity.
• Cache misses. A large share of build time is fetching and compiling the same dependencies. A cache hit turns a five-minute build into thirty seconds, which is a capacity multiplier rather than a latency improvement — and a cache invalidated by a lock-file change affects every project simultaneously after a framework release.
• Per-customer concentration. One account pushing fifty commits should not delay every account that pushed one, which is what a global FIFO produces.
• Abandoned builds. A hung build holds a worker indefinitely, and at scale a small percentage of hangs removes a large fraction of capacity.

The structural controls

• Per-customer concurrency limits and per-customer fair queues rather than one global queue.
• Admission control with honest feedback. When the queue implies an unacceptable wait, show the position rather than accepting silently — a build queued invisibly for forty minutes is worse than a rejection.
• Priority by trigger: a push-triggered interactive build ahead of a scheduled rebuild, and short builds ahead of long ones where fairness allows, since short-job-first minimises average wait.
• Hard timeouts, enforced.

Why builds belong in their own workload class

Bursty, expensive, long-running, untrusted and highly cacheable — five properties that share nothing with serving customer traffic. They need a separate pool, queue and failure domain; interleaving them with the API path means a build spike degrades the platform.

The isolation requirement

Builds run untrusted customer code, so they need genuine sandboxes or microVMs, no shared credentials, egress controls, and no filesystem persistence except an explicit cache. That isolation costs startup time, which is in tension with latency, and the usual resolution is a pool of pre-warmed sandboxes claimed on demand.