Azure Functions Elastic Premium app stops at 20 instances despite 50-instance limits and much higher target worker count?

Question

Azure Functions Elastic Premium app stops at 20 instances despite 50-instance limits and much higher target worker count?

Prachita Mane 0 Microsoft Employee

We have a production Windows Azure Functions app on an EP3 Elastic Premium plan in West US 3. It consistently stops at approximately 20 live instances while processing a sustained Azure Service Bus backlog, even though both the Function App scale limit and App Service Plan maximum elastic worker count are configured as 50.

Runtime target-based scaling appears healthy. Application Insights repeatedly reports:

Target worker count for function 'Host.Functions.CompileShaders' is '1786' (MessageCount='1786', Concurrency='1').

The Service Bus extension is version 5.24.0, runtime scale monitoring is enabled, and host.json intentionally sets maxConcurrentCalls to 1 because each compilation is long-running and CPU/memory intensive. Infrastructure deployment completed successfully and applied the Function App scale limit of 50. No private endpoint or inbound access restriction is defined for the Function App.

Expected: the requested worker count should be clamped to 50 and the app should continue scaling toward that limit.

Actual: the app remains at approximately 20 instances while the backlog and target worker count remain high.

This appears to require examination of Azure backend worker-allocation logs and the effective platform limit for the app/plan. Could a Microsoft engineer please escalate this to a private Azure technical support case? We can privately provide the subscription ID, resource IDs, Terraform apply output, target-worker telemetry, and instance-count graph.

User's image

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-23T05:51:50.0833333+00:00

Hello @Prachita Mane

Reaching out to you over teams!
Christos Panagiotidis 3,551 Reputation points

2026-07-23T06:14:35.5+00:00

The target worker count shown by runtime scale monitoring is a demand calculation, not a reservation. For a Windows Elastic Premium app in West US 3, 20 instances is not the documented maximum, so a stable plateau at 20 deserves checks. Confirm the live functionAppScaleLimit on the app and maximumElasticWorkerCount on the plan, verify the plan is Windows (reserved is false), and check whether other apps on the same plan consume shared workers. Review subscription EP/core quota, Activity Log events, and instance-count metrics during the backlog. If all effective limits are 50 and the app never exceeds 20, this cannot be proven from customer-side telemetry. Open Azure Support with UTC timestamps, app and plan resource IDs, scale-controller target logs, observed instance count, Service Bus backlog, and recent deployment details so the service team can inspect allocation and regional capacity.
Alex Burlachenko 25,120 Reputation points MVP Volunteer Moderator

2026-07-23T09:02:25.5233333+00:00

hi & thx for sharing urs issue here at Q&A portal,

The target worker count of 1786 only shows the demand calculated by the Service Bus scaler. It doesn’t mean the platform has accepted or can allocate that many workers. The result should still be capped by the effective app and plan limits, then scale out gradually. A stable ceiling at roughly 20 instances strongly suggests that an effective maximum burst value of 20 is still being applied somewhere, even though the Function App scale limit and plan maximum elastic worker count show 50. Check the deployed ARM properties and the portal’s Maximum Burst setting, not only the Function App maximum scale-out value. Premium Function Apps have historically defaulted to a maximum burst of 20.

If all effective values really show 50 and the app still never exceeds 20 during sustained backlog, this needs backend investigation. Regional EP3 capacity can also prevent further allocation, but Microsoft should confirm whether the scaler is being capped, throttled, or receiving worker-allocation failures.

Provide the plan and app resource IDs, exact UTC test window, instance-count graph, scale-controller logs, and the deployed values for maximumElasticWorkerCount and functionAppScaleLimit. The Functions team will need to inspect the effective scale configuration and worker-allocation telemetry for West US 3.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-23T09:13:27.1466667+00:00

Hello @Alex Burlachenko We are actively working with the customer and troubleshooting the issue offline as it seems to be a backend issue.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-26T02:42:14.1633333+00:00

Hello @Prachita Mane Can you please try the steps shared offline and let us know if it works!

Your answer

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-23T05:51:50.0833333+00:00

Hello @Prachita Mane

Reaching out to you over teams!
Christos Panagiotidis 3,551 Reputation points

2026-07-23T06:14:35.5+00:00

The target worker count shown by runtime scale monitoring is a demand calculation, not a reservation. For a Windows Elastic Premium app in West US 3, 20 instances is not the documented maximum, so a stable plateau at 20 deserves checks. Confirm the live functionAppScaleLimit on the app and maximumElasticWorkerCount on the plan, verify the plan is Windows (reserved is false), and check whether other apps on the same plan consume shared workers. Review subscription EP/core quota, Activity Log events, and instance-count metrics during the backlog. If all effective limits are 50 and the app never exceeds 20, this cannot be proven from customer-side telemetry. Open Azure Support with UTC timestamps, app and plan resource IDs, scale-controller target logs, observed instance count, Service Bus backlog, and recent deployment details so the service team can inspect allocation and regional capacity.
Alex Burlachenko 25,120 Reputation points MVP Volunteer Moderator

2026-07-23T09:02:25.5233333+00:00

hi & thx for sharing urs issue here at Q&A portal,

The target worker count of 1786 only shows the demand calculated by the Service Bus scaler. It doesn’t mean the platform has accepted or can allocate that many workers. The result should still be capped by the effective app and plan limits, then scale out gradually. A stable ceiling at roughly 20 instances strongly suggests that an effective maximum burst value of 20 is still being applied somewhere, even though the Function App scale limit and plan maximum elastic worker count show 50. Check the deployed ARM properties and the portal’s Maximum Burst setting, not only the Function App maximum scale-out value. Premium Function Apps have historically defaulted to a maximum burst of 20.

If all effective values really show 50 and the app still never exceeds 20 during sustained backlog, this needs backend investigation. Regional EP3 capacity can also prevent further allocation, but Microsoft should confirm whether the scaler is being capped, throttled, or receiving worker-allocation failures.

Provide the plan and app resource IDs, exact UTC test window, instance-count graph, scale-controller logs, and the deployed values for maximumElasticWorkerCount and functionAppScaleLimit. The Functions team will need to inspect the effective scale configuration and worker-allocation telemetry for West US 3.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-23T09:13:27.1466667+00:00

Hello @Alex Burlachenko We are actively working with the customer and troubleshooting the issue offline as it seems to be a backend issue.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-07-26T02:42:14.1633333+00:00

Hello @Prachita Mane Can you please try the steps shared offline and let us know if it works!