# Scale-to-zero & cold starts

Scale to zero when the savings from idle replicas justify the delay and delivery consequences of starting again. A small warm pod is often the better choice for latency-sensitive or slow-starting applications.

| Workload | Zero path | Required evidence |
| --- | --- | --- |
| HTTP service | [Kedify HTTP scaling](https://docs.kedify.io/scalers/http-scaler/) routes/buffers requests during activation | Cold-start time, client/proxy timeouts, retry behavior and readiness fit the service objective. |
| Queue worker | [KEDA scaler](https://docs.kedify.io/scalers/keda-scalers/) observes the queue while workers stop | Durable delivery, acknowledgements, drain/termination and idempotent processing. |
| Application metric | Only if the selected external signal remains observable with no pods | A metric emitted solely by stopped pods cannot reliably activate them. |
| Slow model or stateful warmup | Keep warm capacity or [a smaller warm pod](https://docs.kedify.io/how-to/prp-shrink-pod-instead-of-scale-to-zero/) | Memory/model retention, resize feasibility and latency measured under idle-to-active transitions. |
| Existing Envoy metrics scaler | Keep at least one replica | [Existing Envoy scaling](https://docs.kedify.io/scalers/http-envoy-scaler/) does not provide scale-to-zero activation. |

## Check both directions

[![HTTP requests wait for activation and readiness at zero replicas; a small warm pod retains its process but may still need resource resizing.](https://docs.kedify.io/assets/images/docs/http-cold-start.svg)](https://docs.kedify.io/assets/images/docs/http-cold-start.svg)

Scroll to exploreDiagram description

At zero replicas, Kedify holds the incoming HTTP request while KEDA activates the workload. Scheduling, node provisioning when needed, image pulls and application or model startup occur before a Ready backend can serve the request. A small warm pod retains a process, but restoring resources may still be necessary. Both paths must fit client and proxy timeouts and available capacity.

From active to idle, verify no in-flight request or unacknowledged work is lost. From idle to active, measure time from incoming demand to successful application response—not merely pod creation. Node provisioning, image pulls and model loading are independent delays. Configure [waiting/maintenance pages](https://docs.kedify.io/how-to/configure-waiting-and-maintenance-pages-for-http-scaler/) only when appropriate for the clients; a waiting page is not successful processing of an API request.

## Choose and verify

Use the relevant HTTP or queue tutorial with a bounded test, then repeat it from zero. Set a warm floor if the cold start violates the latency budget. The [small warm pod tutorial](https://docs.kedify.io/how-to/prp-shrink-pod-instead-of-scale-to-zero/) changes resources through PRP rather than stopping the process. Verify its resource transitions and request latency before changing the warm floor.

If activation or scale-in fails, inspect [workload scaling](https://docs.kedify.io/troubleshooting/workload-scaling/) and the signal/timeout path before shortening cooldowns. Restore the previous minimum capacity through the same owner to undo the experiment. Stop when idle behavior and return-to-service time meet the objective; zero is optional.

---
Canonical: https://docs.kedify.io/guides/scale-to-zero/
Source: src/content/docs/guides/scale-to-zero.md
Documentation index: https://docs.kedify.io/llms.txt