Setting the file. One moment.
Subchapter 31.99
references/services/functions/cold-start.mdMarkdown6 KBView on GitHub
Cold starts occur when a function app must allocate infrastructure, load the runtime, and initialize your code before handling a request. Impact and mitigation options differ significantly by hosting plan.
Cold-start duration depends on the runtime, dependencies, package size, and initialization work. Measure the latency of the deployed app instead of relying on a fixed estimate.
| Plan | Platform behavior | Primary mitigation |
|---|---|---|
| Consumption (Y1) | Scales to zero; cold starts are expected | Reduce dependencies and startup work, or move to another plan |
| Flex Consumption (FC1) | Improved scale-from-zero behavior | Configure always-ready instances per function or trigger group |
| Premium (EP1-EP3) | Keeps app-level always-ready instances and an HTTP prewarmed buffer | Configure the app’s always-ready instance count |
| Dedicated | Host runs continuously when Always On is enabled | Enable Always On |
| Container Apps (Functions-on-ACA) | Scales to zero when minReplicas is 0 | Set minReplicas to 1 or higher |
Consumption has no built-in always-ready setting. Reduce the work required to specialize a new instance:
| Strategy | How | Trade-off |
|---|---|---|
| Reduce package size | Trim unused dependencies; use tree-shaking/bundling | Development effort |
| Optimize startup code | Lazy-load heavy modules; defer non-critical connections | Code changes required |
💡 Tip: A timer-based keep-alive isn’t a cold-start guarantee and creates extra executions. If cold starts are a consistent problem, move to Flex Consumption or Premium. See hosting-plans.md for the comparison.
Configure always-ready instances for a function group with the dedicated CLI command (do not hand-edit the functionAppConfig ARM array — indexing into it by position can silently overwrite other always-ready groups):
# Set 1 always-ready instance for the "http" function group
az functionapp scale config always-ready set \
-g $RG -n $APP \
--settings http=1resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
name: appName
location: location
kind: 'functionapp,linux'
properties: {
serverFarmId: flexPlan.id
functionAppConfig: {
runtime: {
name: 'node'
version: '<supported-major-version>'
}
scaleAndConcurrency: {
alwaysReady: [
{ name: 'http', instanceCount: 1 }
]
instanceMemoryMB: 2048
maximumInstanceCount: 100
}
}
}
}⚠️ Warning: Always-ready instances are billed continuously, separate from and in addition to on-demand instances (they don’t count toward
maximumInstanceCount). Start with 1 instance per group and scale based on observed traffic.
Set the app-level always-ready count so this function app stays loaded. The HTTP prewarmed buffer defaults to one instance and usually shouldn’t be changed:
az functionapp update -g $RG -n $APP \
--set siteConfig.minimumElasticInstanceCount=2If you need to reserve plan capacity ahead of scale-out or change its burst ceiling, configure the plan separately:
az functionapp plan update -g $RG -n $PLAN --min-instances 2
az functionapp plan update -g $RG -n $PLAN --max-burst 20
--min-instancesreserves plan capacity. It doesn’t replace the app-levelminimumElasticInstanceCountsetting that keeps a specific app always ready.--min-elastic-worker-countisn’t a valid parameter foraz functionapp plan update.
Enable Always On so the app is never unloaded due to idle timeout:
az functionapp config set -g $RG -n $APP --always-on trueFor new deployments, use the native Microsoft.App/containerApps integration and set kind: 'functionapp'. A generic container app without this kind doesn’t enable the Functions integration. The older Microsoft.Web/sites integration is legacy and planned for future deprecation.
resource functionApp 'Microsoft.App/containerApps@2024-10-02-preview' = {
name: appName
location: location
kind: 'functionapp'
properties: {
managedEnvironmentId: containerAppsEnvironment.id
configuration: {
ingress: {
external: true
targetPort: 80
}
}
template: {
containers: [
{
name: appName
image: containerImage
resources: {
cpu: json('0.5')
memory: '1Gi'
}
}
]
scale: {
minReplicas: 1
}
}
}
}⚠️ Warning:
minReplicas: 0allows scale-to-zero; set it to1or higher to keep at least one replica running. Configure required Functions settings such asAzureWebJobsStoragethrough secrets or managed identity.
| Language | Cold Start Tip |
|---|---|
| .NET | Use ReadyToRun (or Native AOT where supported) compilation; avoid heavy DI registration in startup |
| Node.js | Minimize node_modules; bundle with esbuild/webpack; use the latest LTS version supported by Azure Functions |
| Python | Reduce package count; avoid importing unused modules at the top of the file |
| Java | Prefer the latest supported Java version on Functions v4; minimize static initialization and classpath size |
| PowerShell | Minimize modules declared in requirements.psd1 |
| Scenario | Recommended Plan | Cold Start Strategy |
|---|---|---|
| Cost-sensitive, tolerates latency | Consumption | Small deployment package + minimal startup work |
| Low latency, Linux, bursty | Flex Consumption | 1-2 always-ready instances via az functionapp scale config always-ready set |
| Enterprise, strict SLA, Windows or slots needed | Premium | App-level minimumElasticInstanceCount + default prewarmed buffer |
| Shared App Service plan, always running | Dedicated | Always On = true |
| Containerized Functions | Container Apps (Functions-on-ACA) | minReplicas set to 1 or higher on a Microsoft.App/containerApps resource with kind: 'functionapp' |