# Cold Start vs Warm Start no CI: De Onde Vem a Espera

> Um cold start provisiona um runner novo antes de um job começar; um warm start reutiliza um que já está pronto. Aprenda por que os cold starts deixam o CI mais lento e como os warm pools ajudam.

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

Um cold start significa que um runner precisa ser criado e inicializado antes que seu job sequer possa começar; um warm start significa que já há um esperando. A diferença é o atraso entre a fila e o início que você sente antes de qualquer um dos seus steps rodar.

Antes de um job rodar um único step, um runner precisa existir, inicializar, se registrar e ser atribuído. Se isso acontece sob demanda (cold) ou a partir de um pool pronto (warm) determina quanta espera ociosa fica na frente de cada job.

## O que um cold start inclui

- Provisionar uma instância nova (alocar a VM).
- Inicializar a runner image e iniciar o agente.
- Registrar-se no serviço de CI e receber a atribuição do job.
- Aí então - só então - o primeiro step começa.

## O que um warm start pula

Um warm start puxa de um pool de runners que foram provisionados, inicializados e registrados de antemão. O job é entregue a um deles quase imediatamente, pulando o atraso de provisionamento e inicialização. O primeiro step começa em aproximadamente o tempo que leva para atribuir o job.

## A troca

Runners warm custam dinheiro enquanto ficam ociosos, esperando trabalho. Cold starts custam latência em cada job mas nada enquanto ociosos. Plataformas de runners gerenciados equilibram isso com um warm pool dimensionado à demanda: runners prontos suficientes para absorver a carga normal, com provisionamento cold start para o excedente.

## Por que importa para custo e sensação

O tempo de cold start é tempo morto pelo qual você ainda pode pagar (o setup dentro do job é cobrável) e faz o CI parecer lento, especialmente com muitos jobs curtos. Reduzi-lo - via warm pools e images mais enxutas que inicializam mais rápido - melhora tanto a conta quanto a experiência do desenvolvedor. Um check verde depois de uma fila longa ainda esconde um problema de provisionamento.

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