Short answer
In CI Bench v1, the median wait from a job being created to starting (queue time) was lowest on Self-hosted runners on Google Cloud (1.0 s) and highest on Self-hosted runners on AWS (one VM per job) (51.0 s), taking each configuration's median across the 11 single-job workloads; GitHub-hosted (ubuntu-latest) was 3.0 s. Vitko Runners was 1.5 s (1.5 s with warm starts and test splitting) and Blacksmith 8.0 s; on the burst workload (20 jobs at once) queue times were longer for most configurations, see the burst page. Queue time is not billed on most providers' list prices but adds to how long you wait. Maintained by Vitko, Inc., which sells one of the products measured.
Queue time by configuration
| Configuration | Type | Median queue time | Median p95 queue time |
|---|---|---|---|
| Self-hosted runners on Google Cloud | Self-hosted | 1.0 s | 2.0 s |
| Vitko Runners (warm starts + test splitting)Vitko | Managed | 1.5 s | 2.0 s |
| Vitko RunnersVitko | Managed | 1.5 s | 5.1 s |
| GitHub-hosted larger runner (4 vCPU) | Managed | 3.0 s | 4.0 s |
| GitHub-hosted runners (ubuntu-latest, 2 vCPU) | Managed | 3.0 s | 4.0 s |
| Blacksmith | Managed | 8.0 s | 10.0 s |
| RunsOn | Self-hosted | 18.0 s | 22.0 s |
| Ubicloud | Managed | 18.0 s | 26.0 s |
| Self-hosted runners on AWS (one VM per job) | Self-hosted | 51.0 s | 89.6 s |
Each figure is the median, across the 11 single-job workloads, of that workload's median (or p95) queue time; queue is started_at minus created_at from GitHub's jobs API. The burst workload is on its own page. Per-workload queue times are on each workload page.
More: all questions answered · 12 options compared · ranked by speed · ranked by cost per job · burst workload.
Method: how the runs were made; data: results.json; every raw record: the repository. Maintained by Vitko, Inc., which sells one of the products measured. Page dated October 28, 2026.