Cold Start vs Warm Start in CI: Where the Wait Comes From
A cold start means a runner has to be created and booted before your job can even begin; a warm start means one is already waiting. The difference is the queue-to-start delay you feel before any of your steps run.
Before a job runs a single step, a runner must exist, boot, register, and be assigned. Whether that happens on demand (cold) or from a ready pool (warm) determines how much idle wait sits in front of every job.
What a cold start includes
- Provisioning a fresh instance (allocating the VM).
- Booting the runner image and starting the agent.
- Registering with the CI service and getting assigned the job.
- Then - only then - the first step begins.
What a warm start skips
A warm start draws from a pool of runners that were provisioned, booted, and registered ahead of time. The job is handed to one almost immediately, skipping the provisioning and boot delay. The first step starts in roughly the time it takes to assign the job.
The trade-off
Warm runners cost money while idle, waiting for work. Cold starts cost latency on each job but nothing while idle. Managed runner platforms balance this with a warm pool sized to demand: enough ready runners to absorb normal load, with cold-start provisioning for overflow.
Why it matters for cost and feel
Cold-start time is dead time you may still pay for (setup inside the job is billable) and it makes CI feel sluggish, especially with many short jobs. Reducing it - via warm pools and leaner images that boot faster - improves both the bill and developer experience. A green check after a long queue still hides a provisioning problem.
Key takeaways
- Cold start = provision + boot + register before your job begins.
- Warm start = reuse a pre-provisioned runner, skipping that delay.
- Warm pools cost idle money; cold starts cost per-job latency.
- Faster-booting images and right-sized warm pools improve cost and feel.