Azure App Service SCM/Kudu endpoint returns HTTP 503 — no worker assigned

A stop/start followed by moving the app to a newly created compatible F1 plan is the practical no-cost recovery path; if both the app and SCM endpoint still report 503 with no assigned worker, the remaining fault requires Azure platform support.

1. Force a new app start

In the Azure portal:

1. Open App Services and select the app.
2. Select Stop.
3. Wait until the app reports Stopped, then select Start.
4. Test both:
   • The app’s Default domain from Overview.
   • Development Tools → Advanced Tools → Go.

Restarting or stop/starting is Microsoft’s documented first mitigation for a one-time App Service 503 condition.^1^

SCM Basic Authentication does not assign a worker. Kudu is a companion app created with the App Service app, and deployment operations depend on it; therefore, enabling publishing credentials cannot repair the platform placement identified by the diagnostic message.^2^

2. Run the platform-side detectors

Because Kudu itself is unavailable, use diagnostics that do not depend on its console:

1. Open the app.
2. Select Diagnose and solve problems.
3. Run Web App Down, Availability and Performance, or the offered HTTP 5xx/instance detector.
4. Record:
   • The exact “no worker assigned” result.
   • UTC timestamps.
   • Whether Platform Availability or App Availability is affected.
5. Check Azure Service Health for an App Service incident in the app’s region.

Microsoft’s instance troubleshooting guidance treats unavailable instances and movement to healthy instances as an instance-level scenario.^3^ App Service diagnostics is also the supported collection path when Kudu cannot be opened.^1^

Do not spend additional time changing application code or deployment settings while the platform explicitly reports that no worker is assigned. A failed app startup can produce a 503, but it does not itself explain the absence of a worker for both the site and its SCM companion.

3. Move the app to a new F1 plan

To stay on the Free tier, create another Windows F1 plan and move the app to it. This is the available customer-controlled way to isolate the existing plan without upgrading.

The target plan must be:

• In the same resource group.
• In the same geographical region.
• The same Windows OS type.
• Compatible with any app features currently configured.

Plans created with the same resource-group, region, and OS combination are placed in the same App Service webspace; nevertheless, moving to a separate plan tests a new plan allocation and avoids the state of the current plan.^4^

Portal steps:

1. Create a new App Service plan with Windows and pricing tier F1 in the app’s current resource group and region.
2. Open the affected app.
3. Select App Service plan → App Service plan.
4. Select Change plan.
5. Choose the new F1 plan and select Save.
6. Wait for the operation to finish, then test the main site and SCM endpoint again.

If Change plan does not list the new plan, one of the required compatibility conditions is not satisfied. Virtual network integration must also be disabled before changing plans.^4^

Free plans use shared compute, cannot scale out, and have CPU quotas; they do not provide a dedicated worker.^5^ The regional limit is up to 10 Free App Service plans, subject to other subscription and regional constraints.^6^

4. Use instance replacement only if the portal exposes it

If Monitoring → Health check → Instances shows an assigned instance as Unhealthy:

1. Select that instance.
2. Select Restart.
3. If the restart fails and the portal offers Replace worker, use that option.

Worker replacement affects apps using the same plan and is limited to one replacement per hour. However, Free and Shared plans do not support automatic replacement of unhealthy instances because they cannot scale out.^7^

If there is no instance listed because no worker is assigned, this path is not applicable—proceed to support rather than enabling Health Check solely to create an instance.

5. Escalate a persistent allocation failure

If stop/start and a new compatible F1 plan both fail, open Help + support → Create a support request and select the affected subscription and Azure App Service. Include:

• App and plan resource names.
• Region and Windows/F1 SKU.
• UTC start time and recent failure timestamps.
• The exact diagnostic text: “Currently no worker is assigned.”
• Results for both the main domain and SCM domain.
• Confirmation that moving to a fresh F1 plan also failed.

That evidence distinguishes the issue from publishing authentication, quota consumption, and application startup. Technical support normally requires a support plan, while subscription-management requests do not.^8^

References

1. Troubleshoot HTTP 502 and 503 errors in Azure App Service
2. Kudu service overview - Azure App Service | Microsoft Learn
3. Troubleshoot instance-related issues on Azure App Service
4. Manage an App Service plan in Azure
5. What are Azure App Service plans?
6. Azure subscription and service limits, quotas, and constraints
7. Monitor App Service instances by using Health check
8. Create an Azure support request