Flex Consumption scales beyond maximumInstanceCount (31 instances with a limit of 20)

Question

Flex Consumption scales beyond maximumInstanceCount (31 instances with a limit of 20)

Lars Holm 0

We run an HTTP-triggered Node.js app on the Flex Consumption plan in Sweden Central. functionAppConfig.scaleAndConcurrency is set to maximumInstanceCount: 20, instanceMemoryMB: 2048 and HTTP perInstanceConcurrency: 50. Under a load test of about 500 requests per second the app ran more instances than the limit:

Application Insights showed 28-31 distinct cloud_RoleInstance values per minute for five minutes.
OnDemandFunctionExecutionUnits reached 3,170 GB-s per minute, while 20 x 2 GB x 60 s = 2,400.
The InstanceCount platform metric (Maximum, 1-minute grain) showed 1 for the whole period.

An earlier test with maximumInstanceCount: 10 (512 MB) gave 41 instances and up to 515 GB-s per minute (limit 300). A control test with maximumInstanceCount: 1 was respected (1-2 instances).

The site also reports a legacy siteConfig.functionAppScaleLimit of 100. Setting it to 20 is rejected: "The following site configuration property (Site.SiteConfig.FunctionAppScaleLimit) for Flex Consumption sites is invalid."

Questions:

Is maximumInstanceCount a hard limit on Flex Consumption, or can the platform briefly exceed it (for example during scale-out or when replacing instances)?
Can the legacy functionAppScaleLimit value influence Flex Consumption scaling, and how can it be removed?
Why does the InstanceCount metric show 1 when Application Insights and the billed execution units show many more instances?

Hemant Bharadwaj 180 Reputation points Microsoft Employee

2026-11-04T08:49:31.7+00:00
Thanks for sharing the detailed test data. This behaviour is usually seen when scale observations are mixed across apps/slots or when the metric scope does not match the exact Flex app instance boundary.

First validate the scope of instance counting.

In Application Insights, filter by cloud_RoleName + site name + slot, and check if any stale or parallel workers are being counted together.

In Flex Consumption, scale decisions are app-level and can look higher if telemetry scope is broad.

Verify the configured cap on the running app resource (not only IaC/template).

Re-read functionAppConfig.scaleAndConcurrency from the live resource and confirm maximumInstanceCount is still 20 after last deployment.

Ref: https://learn.microsoft.com/azure/azure-functions/flex-consumption-plan

Correlate with Azure Monitor platform metrics.

Compare App Insights instance count with platform metrics for the same 5-minute windows and same app/slot.

Ref: https://learn.microsoft.com/azure/azure-functions/functions-monitoring

Check for concurrent trigger groups and burst behaviour.

If multiple trigger groups/functions scale independently, total worker observations can appear above expected per-path values during burst periods.

Open a support request with evidence if cap breach is confirmed at platform scope.

Share UTC window, region, app resource ID, sampled instance IDs, and the exact metric queries used.

Confirmed fact from your post: configured maximumInstanceCount is 20 and you observed 28–31 role instances in telemetry during load.

Possible causes: telemetry scope mix, stale instance reporting, or a platform scaling anomaly needing backend verification.

Validation check after fix: under equivalent load, platform-scoped active instance count should stay at or below configured maximumInstanceCount.

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”
Lars Holm 0 Reputation points

2026-11-04T09:45:48.2833333+00:00

@Hemant Bharadwaj Thanks, I've posted the results of your checklist below.

1 answer

Your answer

Lars Holm 0 Reputation points

2026-11-04T09:45:48.2833333+00:00

@Hemant Bharadwaj Thanks, I've posted the results of your checklist below.

Answer 1

Thanks for the checklist. I went through it:

Scope. The limit was read from the running resource (functionAppConfig.scaleAndConcurrency): maximumInstanceCount 10 with 512 MB during the first test and 20 with 2048 MB during the second. The activity log shows no writes to the app between setting each value and the end of each test. The Application Insights resource receives telemetry from this one function app only: every row during both tests has the same cloud_RoleName. There are no deployment slots (Flex Consumption doesn’t support them).

Instances. Filtered on that cloud_RoleName:

Test 1 (2 Nov, 18:44–18:52 UTC, limit 10): 42 distinct cloud_RoleInstance values. 41 of them executed our HTTP functions; the last one only sent host telemetry for one minute.
Test 2 (3 Nov, 21:14–21:21 UTC, limit 20): 31 distinct instances, all 31 executed the HTTP functions.
The app’s only non-HTTP function (a nightly timer) did not run on any of them.

Counted with customMetrics | where name endswith ' Count' | summarize instances=dcount(cloud_RoleInstance) by name and union customMetrics, performanceCounters, traces | summarize dcount(cloud_RoleInstance) by bin(timestamp, 1m). I can share the instance IDs privately.

Billing. The platform metric OnDemandFunctionExecutionUnits also exceeds what the limit allows: up to 3,170 GB-s per minute in test 2, where 20 instances × 2 GB × 60 s = 2,400, and up to 515 GB-s per minute in test 1, where the maximum is 300. That metric is metered by the platform, not by our telemetry, so the gap can’t be explained by the telemetry scope.

We don’t have a paid support plan, so I can’t open a technical case. Could you forward this to the Azure Functions product group? A billing case about the charges is already open.