Cold start
The extra delay when a serverless function has to boot from scratch because nothing was already running to take your request.
See it
What it is
Serverless platforms do not keep your code running. When a request arrives and no instance is warm, the platform has to create a sandbox, load the runtime, pull in your bundle, and run your top-level code before your handler even sees the request. That extra wait is the cold start. Once warm, the same instance handles later requests in milliseconds until the platform reaps it for being idle, on a timetable that is provider-specific and rarely promised in writing.
Size and runtime dominate the cost. A tiny V8 isolate on an edge runtime starts in single-digit milliseconds; a fat Node bundle with a heavy ORM and an AWS SDK import can take a second or more; a JVM or a container image can be worse. The fixes in order of payoff: shrink the bundle, lazy-load the heavy imports that only some requests need, keep the database client out of module scope unless you are caching and reusing it, and use provisioned concurrency or a minimum instance count only when you truly need predictable latency.
The misconception: cold starts are not a bug or a sign of a bad host, they are the price of paying zero when idle. They bite hardest on low-traffic apps, exactly the ones whose owners poke them once an hour and conclude the whole platform is slow. Busy endpoints get them too, though. Scaling out to a new instance, a fresh deploy, an instance dying, and traffic shifting to another region all start something from scratch. Steady traffic hides cold starts, it does not abolish them.
Ask AI for it
Profile this serverless function before changing anything: measure init time against handler time, and cold latency against warm, so we know what we are actually paying for. Then, in that order: delete dependencies the function never uses; lazy-load only the modules that a minority of requests need, since moving an import that every request needs just relocates the same cost into handler time; and initialize the database client lazily but cache it in module scope so warm invocations reuse it instead of reconnecting every call. Report cold latency, warm latency, and deployed bundle size before and after. Only then tell me whether provisioned concurrency, a minimum instance count, or an edge runtime is worth it for my traffic pattern.