New Function App stuck with 0 worker instances for 24+ hours (ServiceUnavailable from host runtime)

Hi @優 水上 ,

your new Function Apps on the Linux Consumption plan never receive a worker instance: the app and SCM endpoints return HTTP 503, zip deployment fails with "Encountered an error (ServiceUnavailable) from host runtime", and diagnostics report the apps running on 0 worker instances for more than 1420 minutes, consistently across three regions in a new free trial subscription.

Is this a documented free trial restriction?

Not for the plan you are using. The restriction that free trial subscriptions do have applies to the Flex Consumption plan, which staff answers describe as blocked on trial subscriptions by design. In a recent thread on that restriction, the Linux Consumption plan was explicitly named as the supported alternative on a free trial. So current documentation and staff guidance do not predict the behavior you are seeing.

What the symptom pattern indicates

Your apps have never received a successful deployment, so application content cannot be the cause; the standard possible cause this detector reports in other threads, a function app taken offline by a previous deployment, does not apply to an app that was never deployed. The identical result in three regions also rules out a single regional incident. What remains is the allocation of dynamic workers for your subscription, which happens entirely on the platform side and cannot be forced from the customer side by restarting or redeploying. A comparable failure was confirmed by Microsoft engineers as a defect in the Linux Consumption backend worker allocation logic in an earlier case, although that incident was regional while yours reproduces in every region you tried.

How to isolate it and get it fixed

1. Create one test app in the same subscription: Windows Consumption plan, Node.js runtime, in a new, empty resource group. Node.js is supported on both Windows and Linux, and a fresh resource group avoids a separate documented limitation around resource pool mapping in existing resource groups. If this app responds without a 503, the failure is specific to Linux Consumption worker allocation for your subscription. If it also returns 503, the problem is broader than one plan.
2. Either way, open a support request in the portal under Help + support, because only Microsoft can repair worker allocation for a subscription. Azure provides unlimited support for subscription management, which includes quota adjustments, while technical support requires a support plan. If the technical category is unavailable on your trial subscription, you can raise the case under subscription management and describe it as a subscription that is not being allocated any compute for the service; include the detector output and the three app names and regions so the engineer can locate the allocation failures directly.

One consideration before you invest more time in this specific plan: the Consumption plan is now documented as a legacy option, Linux Consumption retires on 30 September 2028 and receives no new features or language versions, and Microsoft recommends Flex Consumption for new serverless apps. Given the trial restriction on Flex described above, upgrading to Pay-As-You-Go and creating the app on Flex Consumption would both sidestep the allocation problem you are fighting and avoid building on a retiring plan.

Could you add how you created the apps (portal, CLI, or a template) and whether the Windows Consumption test app in a fresh resource group starts correctly? That result determines whether this is a Linux-specific allocation failure or a broader problem with the subscription.

References

• Free trial subscription is not supported for Flex Consumption (Microsoft Q&A)
• Flex Consumption not available (Microsoft Q&A)
• Azure Function App (Serverless) Returning Frequent 503 (Microsoft Q&A)
• Supported languages in Azure Functions
• Azure Functions hosting options
• Azure Functions Consumption plan hosting (legacy)
• How to create an Azure support request

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against Microsoft Learn and the linked Microsoft Q&A threads.

Based on the symptoms you've described, this looks much more like a subscription or platform capacity allocation issue than a problem with your Function App code, Node.js runtime, deployment package, or chosen region.

The strongest indicator is the diagnostic message:

"Function was running on 0 worker instance for more than 1420 minutes."

In the Consumption plan, Azure Functions relies on dynamically allocated workers. If the platform never assigns a worker instance, the Function host cannot start, which would also explain why:

• https://<app>.azurewebsites.net returns HTTP 503
• https://<app>.scm.azurewebsites.net returns HTTP 503
• ZIP deployment fails with"ServiceUnavailable from host runtime"
• The issue reproduces across multiple Function Apps and multiple regions

When all of these symptoms occur together, it generally points to a hosting or capacity problem rather than an application-level issue.

A few observations stand out:

1. The issue reproduces across three different regions and multiple newly created Function Apps. That makes a misconfiguration in the Function App itself unlikely.
2. Microsoft.Web being registered is necessary but not sufficient. Resource provider registration only confirms that the subscription can use App Service and Functions resources. It does not guarantee that dynamic worker capacity is available.
3. Free Trial subscriptions have quota restrictions. Microsoft documents that Free Trial subscriptions are not eligible for quota increases, so subscription-level limits can sometimes affect resource provisioning behaviour. [learn.microsoft.com], [docs.azure.cn]
4. The fact that the SCM/Kudu endpoint also returns 503 is important. Kudu is part of the hosting infrastructure. If both the application endpoint and SCM endpoint are unavailable, it further suggests the host never successfully started.

What I would check next

• Verify whether any other Consumption-based Function App in the subscription can successfully start.
• Review Subscription > Usage + quotas for any App Service, Functions, or regional quota limitations that may be exposed.
• Try creating a Function App using Flex Consumption rather than Linux Consumption.

Microsoft now recommends Flex Consumption for new Linux-based Azure Functions workloads, and the Linux Consumption hosting option is scheduled for retirement on 30 September 2028. [learn.microsoft.com], [github.com]

Given the 0 worker instances, persistent 503 responses, failed runtime deployment operations, and identical behaviour across multiple regions, I would focus on subscription-level capacity or quota allocation rather than troubleshooting the Function App itself. Until a worker instance is successfully assigned, investigating application code, triggers, deployment packages, or Node.js configuration is unlikely to reveal the root cause.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.