Functions · Updated 10 November 2026 · 8 min read

What are serverless cold starts, and how do you reduce them?

Why the first request after a quiet spell is slow, what drives the delay on functions, containers and V8 isolates, and which fixes each platform offers.

View as Markdown

A cold start is the extra wait on a request that arrives when none of your code is running: the platform has to fetch your code, start a runtime and run your startup code before it can answer. You can shorten that wait in two ways: make startup cheaper with fewer dependencies, less work at load time or a lighter runtime, or pay to keep something running, with provisioned concurrency on AWS Lambda, minimum instances on Google Cloud Run and Scaleway, or a container that never sleeps, as on Scalingo.

Platforms built on V8 isolates, such as Cloudflare Workers and Eurobase, start an isolate, not a container, for each instance of a framework app. Cloudflare says this removes the virtual machine startup, but a first request after a stop still waits for your app's own startup code.

What happens during a cold start

When a request comes in and no environment is ready, Lambda downloads your code, starts the environment and runs any initialization code outside your handler. Only then does the handler run. Later requests that reuse that environment skip all of this, which AWS calls a warm start.

According to the Lambda docs, cold starts typically happen in under 1% of invocations, and each one takes from under 100 ms to over 1 second. They're more common in development and test functions, because those get called less often.

A cold start happens in two situations:

After a quiet period. The platform stops idle instances to free resources, so the next visitor pays the startup.
During a burst. When traffic outgrows the running instances, every new instance starts cold, even if others are warm.

Cold-start controls at a glance

Platform	What starts on a cold request	Ways to shorten or avoid the wait
AWS Lambda	An execution environment	Provisioned concurrency, SnapStart for Java 11+, Python 3.12+ and .NET 8+
Google Cloud Run	A container instance	Minimum instances, startup CPU boost
Scaleway	A container instance	min-scale of 1, CRON triggers, sandbox v2, more vCPU and RAM, smaller images
Vercel	A function	Bytecode caching on Node.js 20+, pre-warming on production deployments
Cloudflare	A V8 isolate inside an existing environment	Isolates replace the virtual machine startup
Scalingo	Nothing, containers stay up	Containers never sleep, so you pay for them while idle
Eurobase	A V8 isolate for frameworks, a container for servers	Lighter startup code; there's no minimum-instance setting

Each row comes from the provider's own documentation, checked on 10 November 2026.

What to check before choosing a fix

How often your traffic goes quiet. A busy API rarely meets one; an admin tool used twice a day meets one almost every visit.
How heavy your startup is. AWS says one-time work such as loading frameworks and module dependencies can take several seconds on the first invocation, so an app that boots a large framework feels the cold start most.
Who pays for warmth. Provisioned concurrency, minimum instances and always-on containers all bill you while nothing happens.
Whether a waiting request can be dropped. Cloud Run holds a request for up to 3.5 times the average startup time of the service, or 10 seconds, whichever is greater. Slow startups during a spike can turn into errors, not just delay.

1. Do less when your code loads

Startup work runs before the first byte of every cold response. Google's Cloud Run tips suggest fewer and smaller dependencies, and loading rarely used code lazily, because the time spent importing modules in Node.js and similar languages adds straight to startup. Scaleway gives the same advice: avoid heavy computation and long initialization at startup, cut the number of libraries and keep the image small.

Deferred work still happens, just later: Cloud Run warns that lazy initialization moves latency onto the first requests to a new instance. Create expensive objects such as database clients once, in global scope, so warm requests reuse them.

2. Give startup more CPU

A slow start is often a CPU-starved start. Cloud Run's startup CPU boost adds CPU while an instance starts and for 10 seconds after: a service with a limit of 1 vCPU or less gets 2 during that window. The boosted CPU is billed for that time. Scaleway also says that adding vCPU and RAM can noticeably reduce the cold starts of a container.

3. Start from a snapshot

Lambda SnapStart runs your initialization when you publish a version, saves a snapshot, and later restores new environments from it. AWS says this can bring startup down from several seconds to as low as sub-second in the best cases. It covers Java 11 and later, Python 3.12 and later and .NET 8 and later. Java pays no extra for it, while on Python and .NET you pay to cache the snapshot and to restore it.

4. Keep instances warm

The large platforms let you pay to keep an instance warm:

AWS Lambda provisioned concurrency keeps environments initialized and is designed for response times in double-digit milliseconds. AWS charges extra for it.
Google Cloud Run minimum instances keep a set number of instances running. With request-based billing, idle instances cost a lower rate; with instance-based billing, the full rate applies all the time.
Scaleway min-scale keeps an instance pre-allocated, and Scaleway notes that it raises your costs. It also suggests CRON triggers to keep a container warm during the hours you need it, without paying for an instance around the clock.

5. Pick a lighter runtime

Cloudflare's Workers docs explain that an isolate is created inside an existing environment instead of a virtual machine for each function, and that this removes the cold starts of the virtual machine model. Vercel takes a different route on its functions: with Node.js 20 or later it caches compiled bytecode after the first run, so later cold starts skip that compilation, and it pre-warms functions on production deployments.

On Eurobase, the isolate runtime is for JavaScript frameworks, while Java and Python servers run as containers. See Cloudflare Workers alternatives in Europe for isolate platforms run by European companies.

6. Don't scale to zero

The most direct fix is a container that never stops. Scalingo's pricing page states that its containers never sleep, starting at €7.20 a month excl. VAT for 256 MB. You pay for the idle hours, and no visitor waits for a boot. The tradeoff between the two billing models is covered in flat vs usage-based hosting pricing.

How cold starts work on Eurobase

Eurobase runs Next.js, Astro, Nuxt and other frameworks on V8 isolates, and servers in Node.js, Python, Go, Java, Ruby, PHP and .NET as containers. Both scale to zero, and there's no setting to keep an instance running.

Apps on V8 isolates. An instance that serves no request for 15 minutes stops, and the host can stop idle ones earlier when it needs memory. The next request starts it again. A cold start must be ready within 5 s and may use up to 2 s of CPU, otherwise the visitor gets 503. CPU spent on startup doesn't count toward your monthly CPU budget.
Containers. Every size scales to zero when idle, and the next request waits for your app to start. Free runs one instance per app, Starter two and Pro three. Starter and Pro add larger sizes up to 1 vCPU and 2 GB, which leave a heavy runtime like the JVM more room to boot.
Price. A Free plan, then Starter at €10 and Pro at €20 a month + VAT for the workspace. Nothing is billed by usage today: work over a limit is refused, apps on V8 isolates and Functions stop until the monthly reset, and containers and static sites keep serving.

If your app can't tolerate a first request that waits for startup, an always-on container elsewhere is the better fit. For JVM apps on Eurobase, see Spring Boot hosting in Europe.

Frequently asked questions

Does every serverless request have a cold start?

No. Only a request that needs a new instance pays it. Once an instance is running, later requests reuse it until it's stopped. AWS puts the share of cold invocations on Lambda at under 1%, though a rarely used function will see many more.

Does pinging my function keep it warm?

It keeps one instance warm, which helps a low-traffic app. Scaleway documents CRON triggers for exactly this. It doesn't help when a burst of traffic needs extra instances, because each new one still starts cold. Provisioned concurrency or minimum instances cover that case, at a cost.

Do V8 isolates have cold starts?

They do, but the unit that starts is much smaller. Cloudflare says isolates remove the virtual machine startup, though your own code still has to load. On Eurobase, a Worker's first request after a stop waits for its startup, which must finish within 5 seconds.

How do I tell if a slow request was a cold start?

Check the platform's own signal. Lambda logs an Init Duration each time an environment is initialized, and Eurobase shows on a Worker's Requests page whether each request was a cold start.