# Cold Start vs Warm Start in CI: Where the Wait Comes From

> A cold start provisions a fresh runner before a job begins; a warm start reuses a ready one. Learn why cold starts slow CI and how warm pools help.

Source: https://latchkey.dev/learn/ci-cd-concepts/cold-start-vs-warm-start-ci  
Updated: 2026-06-25

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.

## FAQ

### What is Cold start vs warm start in CI: where the wait comes from?

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 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt