Glossary

Pipeline queue time

Pipeline queue time is the wait between triggering a run and its jobs starting on a runner — invisible in duration metrics and the clearest signal of runner capacity.

What is pipeline queue time?

Pipeline queue time is the wait between a CI run being triggered and its jobs actually starting to execute on a runner — time spent standing in line before any work begins.

How it is measured

Provider APIs record both moments: when a run or job was created and when it started executing. Queue time is the gap between them, computable from run metadata alone on both GitHub Actions and GitLab CI — no agents, no code access.

The reason it deserves its own metric is that it is invisible in duration metrics. Duration is almost always measured from start to finish, so a pipeline that "runs in six minutes" but waited nine minutes for a runner reports six. The feedback loop a developer actually experiences is queue time plus execution time, and teams routinely optimize only the execution half — because that is the half their dashboard measures.

Why it matters

Queue time is the most direct capacity signal in CI:

  • Saturated self-hosted fleets — more concurrent jobs than self-hosted runners at peak hours shows up as queue time first, long before anyone notices.
  • Concurrency limits — hosted-runner plans cap parallel jobs; hitting the cap queues everything behind it.
  • Load patterns — spikes at specific hours point to contention (everyone pushes before standup); uniform growth points to a fleet that is simply undersized for the team.

The shape of the distribution matters as much as the average: a healthy pipeline can hide a brutal tail where one run in twenty waits ten times longer than the median, which is the same reason duration percentiles beat averages. If developers describe CI as slow, splitting the complaint into "waiting for a runner" versus "running too long" is the first diagnostic step — the two have entirely different fixes, one of them being capacity and the other being pipeline optimization.

TrimCI reports queue time per repository in its PDF reports, computed from provider run metadata and shown next to duration percentiles and failure cost — so a slow-CI investigation starts by separating the line from the work.

← All CI/CD terms

schedule Fast setup · 14-day free trial

See what your CI failures actually cost.

Connect GitHub Actions or GitLab CI with read-only access — never your source code — and get a ranked, dollar-costed fix list from your own pipeline data.