High Cold Start Rate
Percentage of invocations that are cold starts with elevated init duration
What this means
A cold start happens when Lambda creates a new execution environment to handle an invocation. This involves downloading your deployment package, starting the runtime, and running your initialization code (module imports, SDK client construction, database connection setup) before the handler can execute. Cold starts add anywhere from 100ms to several seconds of latency to the affected invocation, depending on your runtime, package size, and VPC configuration.
A high cold start rate means that a large percentage of your invocations are paying this initialization penalty rather than reusing a warm execution environment. This typically happens when your function has low, infrequent traffic (environments get recycled after minutes of inactivity), when you deploy frequently (each deployment invalidates all warm environments), or when traffic spikes trigger a burst of new environments faster than Lambda can reuse existing ones.
Detection criteria
smplogs triggers this finding when:
- ●HIGH — More than 30% of invocations are cold starts
- ●ELEVATED — More than 15% of invocations are cold starts
Example finding
37.2% of invocations were cold starts (312 of 839). Average init duration: 1,847ms. Cold starts concentrated in the first 5 minutes of each hour, suggesting scheduled traffic patterns.
How to fix
Enable Provisioned Concurrency
Provisioned Concurrency keeps a specified number of execution environments initialized and ready to respond instantly. Set it to match your baseline traffic level — for example, if you typically handle 50 concurrent invocations, provision 50. You can also use Application Auto Scaling to adjust provisioned concurrency based on a schedule or utilization target. This eliminates cold starts for all invocations served by provisioned environments, but you pay for the provisioned capacity whether it is used or not.
Reduce deployment package size
Lambda must download and extract your deployment package during a cold start. A 50MB zip takes measurably longer than a 5MB one. For Node.js, use tree-shaking and bundle with esbuild to eliminate unused dependencies — the AWS SDK v3 modular packages are much smaller than the monolithic v2. For Python, avoid packaging large frameworks when a lightweight alternative exists. For Java and .NET, consider using Lambda SnapStart or Native AOT compilation respectively, which can cut cold start times by 90%.
Move initialization outside the handler
Code at the module level (outside the handler function) runs once during cold start and is reused across subsequent invocations. Move SDK client construction, database connection pools, configuration loading, and secret retrieval to the module scope. This does not reduce cold start duration itself, but it ensures that warm invocations are as fast as possible and that the initialization cost is amortized across all invocations that reuse the environment.
Use a lighter runtime
Runtime choice has a significant impact on cold start duration. Node.js and Python consistently have the fastest cold starts (100-400ms typical). Java and .NET are substantially slower without SnapStart/Native AOT (1-5 seconds). If your function is latency-sensitive and you are using Java, either enable SnapStart (which creates a pre-initialized snapshot of the execution environment) or consider rewriting the function in a lighter runtime. Go and Rust with the provided.al2023 custom runtime also have extremely fast cold starts.
Related patterns
Scan your logs for this pattern — try smplogs free.
Try it free