engineering
How we cut runner start time to three seconds
Warm pools, snapshot restore and the unglamorous work of predicting demand.
Priya Raghavan · Infrastructure · 2026-04-02 · 8 min read
Cold start is invisible in step timings and extremely visible to developers. On a 90-second job, a 60-second start doubles the perceived pipeline time.
Three things that mattered
- Warm pools sized against predicted demand rather than a fixed count
- Snapshot restore rather than boot, so the machine resumes instead of initialising
- Pre-registering runners with GitHub before a job is assigned, so registration is off the critical path
The prediction problem
Holding too few warm machines means queueing. Holding too many means paying for idle. Demand is strongly correlated with the working hours of each customer's team, which makes it more predictable than it first appears — and the residual burst is what the pool headroom absorbs.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
CI when your teammates are agentsAI coding agents push far more often than humans. Here is how that changes pipeline design and cost control.Why we publish instructions for leavingEvery migration page on this site includes the diff to migrate back off us. Here is the reasoning.What we learned running a million CI jobsQueue time, cache behaviour, right-sizing and the failure modes that only appear at scale.Stop retrying flaky testsAutomatic retries convert a real bug into an intermittent one, and train your team to distrust every failure.