Cold Start Latency Vocabulary

Cold start latency is the noticeable extra delay a serverless function experiences on its first invocation after being idle, caused by the underlying infrastructure needing to initialize a new execution environment before the function can actually run. A subsequent request shortly after typically reuses that already-initialized environment, responding much faster in what's called a warm invocation. This latency difference is an important characteristic to understand when evaluating serverless architecture for a latency-sensitive use case.

Scheduled warm-up invocations periodically send a lightweight request to a serverless function specifically to keep its execution environment initialized, reducing the chance a genuine user request arrives during a slower cold start. Letting every function's environment fully shut down between requests with no proactive warm-up maximizes cold start frequency for a function with irregular traffic. This warm-up technique is a common mitigation, though it adds a small ongoing operational cost to maintain.

Provisioned concurrency keeps a minimum number of a function's execution environments pre-initialized and ready at all times, essentially eliminating cold start latency for invocations within that provisioned capacity, in exchange for an ongoing cost even when the function isn't actively being invoked. Allowing every invocation to always start cold avoids that ongoing cost but accepts the latency penalty on every first request after idle time. This tradeoff between cost and consistently low latency is a deliberate configuration decision for a genuinely latency-sensitive serverless function.

Configuring provisioned concurrency or another warm-up strategy for a critical function ensures a sufficient number of environments are already initialized and ready before a traffic spike actually hits. Relying entirely on cold starts means a sudden spike forces many simultaneous cold-start delays right when fast response times matter most. This proactive latency mitigation is especially important for a function on a genuinely critical, user-facing path where slow response times have real business impact.

Accepting occasional cold start latency to save cost is a reasonable choice for a function where a slow response now and then doesn't meaningfully hurt the user experience or business outcome. For a function on a genuinely critical, latency-sensitive path, that occasional slow response can have a real negative impact, justifying the added ongoing cost of provisioned concurrency. This is a deliberate, context-dependent tradeoff rather than a universal rule to always or never pay for provisioned concurrency.