Newly created Linux Consumption Function Apps stuck "Service Unavailable" (503) despite state=Running

Question

Newly created Linux Consumption Function Apps stuck "Service Unavailable" (503) despite state=Running

Markus 0

Hello,

Summary

Every Linux Consumption Plan Function App I create in a specific subscription becomes permanently unreachable ("The service is unavailable.", HTTP 503) on both the main site URL and the SCM/Kudu endpoint, even though the control plane (az functionapp show) reports state: Running the entire time. This has now happened identically three times in two different regions, so it doesn't look like a one-off provisioning glitch.

Environment

Subscription: Pay-as-you-go (Basic support plan) Function Apps: Linux, Consumption (Y1) plan, Node.js runtime 24, Functions v4 CLI: az (latest), Windows PowerShell

What I tried, in order

Attempt 1 — func-app-1 (West US 2) Created successfully (state: Running). Main URL and https://<app>.scm.azurewebsites.net both returned "The service is unavailable." for over an hour. Manual az functionapp restart did not help. Deleted after ~1 hour with no change.

Attempt 2 — func-app-2 (West US 2, fresh name + fresh instance) Same symptom immediately after creation. Confirmed via the Portal's built-in Diagnose and solve problems → Function App Down or Reporting Errors → "Functions that are not triggering" detector:

Host Runtime instance (Consumption Plan) was unavailable for a sustained time period (> 15 minutes) Function was running on 0 worker instance for more than 1420 minutes

az functionapp restart did not resolve it. az functionapp deploy --type zip failed immediately with:

An error occurred during deployment. Status Code: 503, Details: The service is unavailable.

— failing at the SCM connection stage, before any file transfer. Deleted this app and its auto-created App Service Plan.

Attempt 3 — func-app-3 (East US 2, different region, fresh App Service Plan, fresh Storage Account in the same region as the Function App) Same symptom again: state: Running, but main URL and SCM endpoint both return "Service unavailable." from the moment of creation, persisting overnight (checked again ~18 hours later — no self-healing). Zip deploy fails the same way as Attempt 2.

Other checks performed

az appservice plan list — the underlying Consumption plan shows ProvisioningState: Succeeded, Status: Ready in all cases. Resource providers Microsoft.Web, Microsoft.Storage, Microsoft.OperationalInsights are all registered. Azure Service Health → Service Issues: no active incidents reported for this subscription/region at any point. Region West Europe is blocked for new resources on this subscription ("not accepting new customers"), which suggests this subscription may have some kind of restriction/flag — possibly related, possibly not. Storage account co-located in the same region as the Function App (ruled out cross-region storage latency as the cause).

Question

Is there a known issue where newly created Function Apps on a subscription can get stuck with a healthy control-plane state but a completely unreachable data-plane (site + SCM both down)? Is there a subscription-level flag or backend allocation issue that could cause this consistently across regions? Any pointers on further self-service diagnostics, or confirmation that this needs a support ticket, would be much appreciated.

Likhitha Sulake 105 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-07-21T11:49:02.7333333+00:00

Please let us know whether the issue has been resolved. If not, please try the instructions I shared above and update us.

1 Antwort

Ihre Antwort

Likhitha Sulake 105 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-07-21T11:49:02.7333333+00:00

Please let us know whether the issue has been resolved. If not, please try the instructions I shared above and update us.

Answer 1

Hi @Markus ,

Welcome to Microsoft Q&A, and thank you for providing such a detailed investigation summary and the troubleshooting steps you've already performed.

Based on the information you've shared, this does not appear to be an application-level issue. The behavior is occurring across multiple newly created Function Apps, different Storage Accounts, and multiple Azure regions, while the Function Apps consistently remain in a Running state from the control plane.

The most significant observations are:

Both the application endpoint and the SCM (Kudu) endpoint immediately return HTTP 503 (Service Unavailable) after creation.

Zip deployment fails before any content is transferred, indicating that the SCM site is unavailable rather than the deployment package itself. The Function App Down or Reporting Errors detector reports: Host Runtime instance (Consumption Plan) was unavailable for a sustained time period (>15 minutes). Function was running on 0 worker instance... The behavior is reproducible across different regions, fresh Storage Accounts, and newly created Function Apps.

These findings suggest that the issue is more likely related to platform provisioning or backend worker allocation rather than the Function App configuration itself.

Additional checks to perform

Although you've already completed most of the common troubleshooting, I recommend verifying the following before proceeding with a support request.

Review the Activity Log

Navigate to your Resource Group or Function App and review the Activity Log for any failed provisioning events or platform-side errors that may have occurred during creation.

Verify the Function App Configuration

Confirm that the Function App is associated with the expected runtime and storage configuration:

In particular, verify that:

reserved is set for Linux.
kind reflects the expected Function App configuration.
Required application settings such as AzureWebJobsStorage and FUNCTIONS_WORKER_RUNTIME are present.

Verify Storage Account Connectivity

Since the Functions runtime depends on the configured Storage Account during startup, confirm that:

The Storage Account is accessible. There are no networking restrictions (firewall, private endpoints, or virtual network rules) preventing access. The Function App can reach the Storage Account.

Although you've already tested with newly created Storage Accounts in the same region, validating connectivity helps rule out startup dependencies.

Review Diagnostic Information

Since the detector reports that the host runtime is running on 0 worker instances, review any available diagnostics under:

Diagnose and solve problems → Function App Down or Reporting Errors

for additional platform events or runtime allocation failures.

Test a Different Hosting Plan

If feasible, create a temporary Function App using a different hosting plan (for example, Flex Consumption or Premium) within the same subscription.

If the issue is isolated to Linux Consumption (Y1) while other hosting plans function normally, this would further indicate a platform allocation issue specific to the Consumption plan.

Verify Subscription Limits or Restrictions

Although your resource providers are registered and Azure Service Health reports no active incidents, the fact that the issue is reproducible across regions raises the possibility of a subscription-level restriction or backend allocation issue.

You can review your subscription's usage and quotas to confirm that there are no exhausted limits affecting Function App provisioning.

Hope this helps. Please let us know if you have any further questions. Thank you.