How do I configure auto-scaling AND troubleshoot cold starts on Azure Functions?

On the Consumption plan, Azure Functions automatically performs event-driven scale-out, while cold starts cannot be eliminated; configure only an optional scale-out ceiling, then enable the .NET 8 isolated placeholder and ReadyToRun optimizations to reduce startup latency.

Configure scaling on Consumption

The scale controller monitors incoming events and adds or removes host instances. Consumption uses app-level scaling, so every function in the same function app shares resources and scales together; it does not use user-defined CPU or memory autoscale rules. For HTTP triggers, new instances are allocated at most once per second.^1^

1. Leave scaling unrestricted unless a downstream system needs protection.
   Check the Function App’s functionAppScaleLimit site setting. A value of 0 or null means unrestricted within the plan’s platform limits.
2. Set a lower maximum only when necessary, such as protecting a database from excessive concurrent connections:

      az resource update \
        --resource-type Microsoft.Web/sites \
        --resource-group <RESOURCE_GROUP> \
        --name <FUNCTION_APP>/config/web \
        --set properties.functionAppScaleLimit=20
   

3. Do not set the limit too low. A low ceiling can increase HTTP latency or cause requests to be rejected during peak load. Load-test at expected peak traffic before imposing the limit.^1^

Also check that no Daily Usage Quota was left from development and that trigger concurrency or singleton behavior is not artificially restricting scaling.^2^

Reduce .NET 8 isolated cold starts

After several idle minutes, Consumption may scale the app to zero. The next HTTP request must allocate an instance and start the host and isolated worker. This is expected on legacy Consumption, which has no always-ready or Always On option.^1^

1. Enable the .NET isolated placeholder

Use current startup dependencies—Microsoft.Azure.Functions.Worker 1.19.0 or later and Azure.Functions.Sdk 1.0.0 or later—then enable the placeholder optimization:

az functionapp config appsettings set \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP> \
  --settings WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1

az functionapp config set \
  --resource-group <RESOURCE_GROUP> \
  --name <FUNCTION_APP> \
  --net-framework-version 8 \
  --use-32bit-worker-process false

The target framework must be .NET 8 or later, and the app should run as a 64-bit process. App-setting changes restart the function app, so expect one startup cycle after applying them.^3^^4^

Make sure the project contains the required references:

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker"
                    Version="1.21.0" />
</ItemGroup>

Incorrect framework or architecture configuration can prevent an app using placeholders from starting.^3^

2. Publish ReadyToRun binaries

ReadyToRun performs ahead-of-time compilation and can reduce Consumption-plan startup time. Add settings matching the app’s operating system and architecture:

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <PublishReadyToRun>true</PublishReadyToRun>
  <!-- Use linux-x64, win-x64, or win-x86 to match the Function App. -->
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
</PropertyGroup>

Publish and deploy that output:

dotnet publish -c Release

A runtime-identifier mismatch causes startup failure, so verify the Function App OS and 32/64-bit setting before deployment.^3^

Distinguish cold start from slow execution

Test the same endpoint twice:

1. Leave the app idle long enough to permit scale-to-zero.
2. Record the first request’s duration.
3. Immediately repeat the request several times.
4. Compare application logs and dependency timings.

A slow first request followed by fast warm requests indicates startup cost. If every request remains slow, investigate function code and outbound dependencies instead. Reduce startup work by trimming unnecessary dependencies and avoiding expensive initialization before the host can process requests—the dependency count directly affects cold-start time.^1^

If predictable low latency is mandatory, migrate to Flex Consumption and configure always-ready instances, or use Elastic Premium with prewarmed/always-ready instances. Both retain dynamic scaling while providing supported cold-start mitigation.^5^

References

1. Event-driven scaling in Azure Functions (consumption-plan)
2. Best practices for reliable Azure Functions
3. Guide for running C# Azure Functions in the isolated worker model
4. App settings reference for Azure Functions
5. Azure Functions hosting options