Why the Kudu site for my app service is showing 503 Service Unavailable

Viewed 6498

I am having trouble deploying container to my app service in Azure. In the release pipeline, I saw the following error

[debug][PUT]https://$iagadsca01-cac-app-salesforcedownstream-01:***@iagadsca01-cac-app-salesforcedownstream-01.scm.azurewebsites.net/api/deployments/16801603731950666 [debug]Could not parse response: {} [debug]Response: undefined [debug]Encountered a retriable status code: 503. Message: 'Service Temporarily Unavailable'.

The pipeline will repeat the the above PUT operation for 20 mins and times out eventually.

When I try to open the Kudu site (*.scm) site for my web app, it just gave me a blank page with error

Service Unavailable

I think the scm site should be up regardless my app is running or not? What could cause the scm site to give Service Unavailable error?

3 Answers

TL;DR: scale up the app service plan and scale back.

This is now solved after I had a support call with MSFT on Teams (my employer has a very high level SLA with MSFT, I was contacted in two hrs after submitting a request), see my summary here:

The support engineer found errors related to vNet for the app service and suggested to disconnect the app service from the vNet. We did that and the issue was solved – the scm site is no longer throw 503 error.

We enabled vNet connection again, and scm site started to give 503 error again. We thought we know the cause is vNet.

Then we kept the vNet connected, and scaled up the app service plan and scaled back – this will cause the app service migrate to another VM instance. After that – the scm remained working!

So we didn’t know if it is vNet which caused problem. The underlying VM probably messed up.

Another possibility where I've seen this occur is in a faulty ARM deployment where the Azure App Service Plan for Linux did not have the reserved property set to true, and the Operating System defaulted to Windows despite the linux plan. Any app service deployed to that plan, configured correctly or otherwise, would appear to be ready to accept a code deployment, but would not successfully start, silently.

RobReagan's comment is right, this should not occur in a properly created resource, even with failed code deployments.

My apps service plan was running approx 10 apps and was at 93% memory. I shut down one of the apps, it dropped somewhere in 80% memory, and I could access the SCM sites again.

Its worth a try.

Related