A serverless function that responds instantly under load can take noticeably longer on its first invocation. That delay is the cost of creating an execution environment that did not previously exist.
What has to happen before code runs
The platform must allocate a sandbox, attach networking and storage, load the runtime, fetch the function package and initialise the language environment before a single line of user code executes.
Each of those steps takes time that scales differently. Sandbox creation is fairly constant, while package fetching depends on size and runtime initialisation depends on the language.
Once warm, the environment is retained for a period and subsequent requests skip all of it, which is why the same function shows two very different response profiles.
Runtime choice dominates the difference
Interpreted runtimes generally start quickly because there is little to prepare beyond loading the interpreter and parsing the code.
Runtimes with heavier initialisation, particularly those that build large dependency graphs or perform reflection at startup, spend substantially longer before the handler is reachable.
Compiled languages that produce a self-contained binary avoid most of this, which is why they are common in latency-sensitive serverless workloads despite being less convenient to write.
Dependencies are the usual culprit
Function packages grow as libraries are added, and every additional megabyte must be fetched and unpacked before execution. Large packages lengthen every cold start.
Initialisation code that runs at module load, such as opening database connections or reading configuration, adds directly to the cold path even when the request would not have needed it.
Moving that work behind a lazy check so it happens only when required is one of the few changes that improves cold starts without changing the platform.
Traffic shape determines how often it happens
A function receiving steady traffic keeps environments warm and rarely pays the cost. One invoked occasionally pays it on almost every request.
Scaling events also produce cold starts, because a burst of traffic requires new environments even though existing ones are warm. Rapid growth is when users notice it most.
Provisioning warm capacity trades cost for latency
Platforms offer the option to keep a number of environments initialised and idle, which removes the cold path for that many concurrent requests.
This is billed continuously rather than per invocation, which reverses the economic premise of serverless for that portion of capacity.
The decision is therefore about which requests genuinely need predictable latency, since paying to keep everything warm converts a usage-based system back into a provisioned one.