Your Azure Function works perfectly under load, but the first call after a quiet stretch is painfully slow — sometimes slow enough that the caller times out. Then it is fast again. This is a cold start, and it is one of the most common serverless surprises. Here is what is happening and how to fix it.
What a Cold Start Is
On the Consumption plan, Azure deallocates your function's compute when it is idle. The next request has to allocate a worker, load your runtime, and initialize your code before it can respond. That startup time — often several seconds — is the cold start. Warm invocations skip it entirely because the worker is already running:
Idle → request arrives → allocate worker → load runtime → init code → run (slow)
Warm → request arrives → run (fast)
Cause 1: Heavy Initialization
If your function loads large dependencies or opens connections at startup, the cold start balloons. Move expensive setup out of the hot path and reuse clients across invocations by declaring them at module scope, not inside the handler:
// Created once per worker, reused across invocations private static readonly HttpClient client = new HttpClient(); public static async Task<IActionResult> Run(HttpRequest req) { var result = await client.GetAsync("https://api.example.com/data"); // ... }
Cause 2: The Consumption Plan Itself
Cold starts are inherent to the Consumption plan. If your latency budget can't absorb them, move to the Premium plan, which keeps pre-warmed instances ready so requests never hit a cold worker:
az functionapp plan create \ --resource-group my-rg --name my-premium-plan \ --sku EP1 --location eastus
Cause 3: Large Deployment Package
A big deployment package takes longer to load onto a fresh worker. Trim unused dependencies and run from a package file so the runtime mounts it quickly instead of copying thousands of files.
Summary
A first-call timeout is almost always a cold start: idle functions get deallocated and the next request pays for worker allocation and initialization. Slim down startup work and reuse clients at module scope, shrink your deployment package, and if cold starts still break your latency budget, move to the Premium plan for pre-warmed instances. Match the plan to your latency needs and the first-call penalty disappears.