We are seeing an SCM/Kudu routing failure on selected Windows Azure App Service applications configured for .NET 10.
An authenticated request to the affected app’s SCM endpoint, such as:
https://<app>.scm.azurewebsites.net/api/environment
returns:
HTTP 503
Reason: SiteRoutedToIncorrectWorker
Body: The service is unavailable.
The application endpoint itself remains available. The anonymous SCM endpoint returns HTTP 401 as expected, but authenticated SCM requests fail with the routing error. This prevents Kudu, Advanced Tools, Web Deploy, ZIP Deploy and OneDeploy from working.
What we have established:
- A Windows .NET 10, 64-bit app on the existing App Service plan reproduces the problem.
- A newly created .NET 10 app on that same plan also reproduces it.
- Changing an affected app to the .NET 9 App Service stack restores Kudu access.
- A self-contained .NET 10 application runs successfully when the App Service stack is left at .NET 9. This is our current workaround.
- Some older .NET 10 applications on the existing plan still have healthy Kudu endpoints.
- A fresh Windows .NET 10, 64-bit app created on a completely new App Service plan successfully completed an ARM-authenticated OneDeploy operation through Kudu.
Troubleshooting already performed:
- Verified the apps are enabled, running and report normal availability.
- Verified public network access and SCM IP restrictions.
- Verified publishing authentication policies.
- Reset publishing credentials and downloaded new publishing profiles.
- Tested publishing-profile and Entra authentication.
- Restarted the affected app.
- Performed a complete Stop, confirmed Stopped, then Start.
- Tested Always On enabled and disabled.
- Verified CURRENT_STACK=dotnet and netFrameworkVersion=v10.0.
- Verified 64-bit worker configuration.
- Checked App Service diagnostics and Activity Log; management operations report success.
- Checked Resource Health; no relevant active incident was shown.
- Checked plan metrics; there was no sustained CPU saturation or HTTP request queue.
- Confirmed that healthy and failing apps can be allocated to the same plan worker.
The full Stop/Start and configuration changes did not clear the failure.
The evidence suggests a per-site SCM worker registration or routing problem triggered when some Windows apps are newly created or reconfigured for .NET 10. A fresh app on the existing plan fails, while an equivalent app on a fresh plan succeeds.
Has anyone encountered this with Windows App Service and .NET 10? Is there a supported way to force Azure to rebuild or refresh the SCM companion site’s worker registration without moving the application to a new App Service plan?
The exact platform substatus is:
503 SiteRoutedToIncorrectWorker
Similar question here: https://learn.microsoft.com/en-us/answers/questions/5997557/app-service-windows-net-10-returns-503-siteroutedt