Cold starts and pricing are two sides of the same coin. The reason serverless costs $0 while idle is that it scales to zero — and the price of scaling to zero is that the next request has to wake something up. How much that costs you, in both latency and money, depends on the platform.
Cold-start latency by runtime type
| Runtime type | Examples | Typical cold start |
|---|---|---|
| V8 isolates (edge) | Cloudflare Workers, Deno Deploy | ~milliseconds |
| Container FaaS | AWS Lambda, Cloud Run, Azure Functions | ~0.2-2 seconds |
| Free spin-down instances | Render free tier | 30-60 seconds |
Snapshot captured June 2026.
How billing model changes the cost of a cold start
- Wall-clock GB-second billing (Lambda, Azure Functions): the cold-start initialisation time is part of the billed duration, so a slow cold start costs both latency and money.
- CPU-time billing (Cloudflare Workers, Vercel active CPU): you’re billed on CPU execution, not wall-clock, so cold-start wait time is largely free — the cost is purely latency.
This is the same wall-clock-vs-CPU-time distinction that makes I/O-bound code cheaper on Workers than Lambda (see the true cost comparison).
Paying to remove cold starts
Every major FaaS lets you keep instances warm — provisioned concurrency (Lambda), min instances (Cloud Run), always-ready (Azure Flex Consumption). They work, but they remove scale-to-zero and add a fixed cost, so you’re back to paying for idle time. That’s the fundamental trade-off:
Scale-to-zero = cheapest when idle, slowest first request. Warm instances = fastest, but you pay for idle.
See which platforms scale to zero and which bill while running.
Bottom line
If latency on the first request matters, prefer an edge runtime (millisecond cold starts) or pay to keep a minimum warm. If cost matters more than tail latency, embrace scale-to-zero. Either way, model the billed duration — including init time on wall-clock platforms — in the calculator.