Skip to content
OrionHub Developer tooling and cloud development
Section
performance
Kind
Editorial
Reading time
4 min
Updated
8 September 2026

Cold Starts in Serverless Architectures: The Anatomy of Startup Delays

Cold starts are not just an annoyance for developers dealing with short intervals of server downtime. They are actually a chain of delays, each one a distinct part of the process that happens when a server or container has been idle. Understanding what causes cold starts and how to mitigate them is crucial for developers aiming to create efficient and responsive serverless applications.

What Is a Cold Start?

A cold start occurs when a function is invoked after a period of inactivity or during rapid scale-up. In AWS Lambda, a cold start happens when there isn’t an existing execution environment available, and a new one must be created. Similarly, Azure Functions defines a cold start as an increase in latency for functions that haven’t been called recently. Runpod explains that a cold startup starts with no running workers, goes through a provisioning and startup phase, followed by runtime and framework initialization, and finally handles the first request. In short, a cold start is the delay between receiving a request and the time a worker is fully ready to handle it.

Where the Time Goes

Cold starts in serverless platforms are complex events that occur in several steps. These are just a few:

  1. **Image or Bundle Pull: After provisioning, the platform often needs to fetch the latest image or bundle, especially if it’s a new function or version. This can introduce significant delay, particularly for larger assets. When a Docker image is not cached, Fal.ai documents that the additional provisioning includes a Docker Pull before Setup. Runpod also documents that larger models take longer to load from disk or network, increasing cold start time.
  1. Container Provisioning and Setup: Once the image is available, the container needs to be provisioned and set up. AWS documents that cold starts include initialization steps for an execution environment. Runpod also notes that cold startup involves starting the container. This step can vary widely in duration based on the platform, load, and available resources.

Bundle Size and Startup Cost

In addition to platform and runtime factors, the size of the application code bundle also plays a significant role in cold start times. Larger bundles take longer to download and unpack, delaying the initiation of the runtime and application frameworks. For Lambda functions, Zod Mini states that the minimum cold start time for a negligible 1kb bundle is 171ms. The AWS SDK v3 GitHub issue reports cold start times rising with bundle size increases.

Furthermore, larger runtime environments and frameworks that have to be loaded and initialized can also extend the startup time. This is especially relevant in languages like Java, where bundles can grow large, or in frameworks that do runtime code generation or compilation. Bref says its PHP runtimes add a cold start of about 250ms on average.

Warm Instances and Mitigations

One common approach to avoiding cold start delays is to keep instances warm. This means maintaining a pool of preinitialized instances ready to handle requests immediately. Otherwise, platforms like Runpod and Fal.ai trigger images to load models into memory, and Bref triggers instances to startup and begin task-running. However, this can also increase costs and resource utilization, particularly for functions with irregular traffic patterns.

To mitigate cold start times, platforms like Runpod recommend using cached models and enabling features like FlashBoot, which reduces load times. Likewise, Fal.ai suggests preloading Docker images to avoid the Docker Pull delay. These technical recommendations aim to reduce specific bottlenecks in the cold start sequence.

Additionally, reconsidering the choice of runtime and commonly used libraries can also have an impact. For instance, languages with faster start-up times and more efficient core libraries can help reduce cold start times significantly. Finally, certain platforms provide options to specify the number of active workers or concurrency levels, which can help in keeping instances warm for frequently accessed functions.

Cold Starts as a Symptom, Not a Problem

While cold starts can be seen as a problem in serverless architectures, they are often a symptom of a larger issue: the misuse of the execution model. Serverless functions are designed to be stateless and ephemeral, but certain workloads, particularly those with high processing requirements or stateful operations, may not be a good fit.

This mismatch in execution models can lead to frequent cold starts and performance issues. For instance, using serverless for complex machine learning models rather than long-running background tasks can result in high-latency cold starts and inefficient resource utilization.

In such scenarios, choosing a more appropriate execution model, such as container services or traditional servers for background processing, can help avoid the limitations of serverless functions. By aligning the execution model with the workload nature, developers can inherently reduce cold start issues and improve overall performance.