Philippines staffing research ·

What CI queue time can tell you, and what it cannot

What CI queue time can tell you, and what it cannot

A source-led method for separating scarce runners from slow jobs and incomplete pull requests.

A build can wait because no runner is free, because a concurrency rule blocks it, or because an earlier workflow still owns the slot. Treating all of that time as test execution hides the part a team can change.

GitHub documents runner queues and concurrency controls. DORA studies delivery as a system. Those sources support separating queue states from execution states, but they do not supply a universal acceptable wait time.

Method: select one repository and a fixed observation window. Record workflow creation, eligibility, runner assignment, job start, completion, cancellation, event type, and concurrency group. Split ordinary changes from urgent repairs before calculating a median and an upper percentile.

Scope and inference limits: the result describes the sampled workflows and runner pool. It may reveal capacity pressure or a blocking rule. It does not measure developer effort, test quality, or the value of a change.

Limitations: reruns, cancellations, changed runner labels, and missing timestamps can distort the sample. Publish the count and exclusions. The company owner retains runner purchasing and release policy.

Sources

  1. GitHub Actions hosted runners
  2. GitHub Actions concurrency
  3. DORA research

Related Research

FAQ

What should happen first?

Begin with a bounded ticket, approved access, and a named reviewer.

Who approves production changes?

The company’s technical owner keeps final merge and release authority.