Azure Pipelines: "Failed to deploy web package to App Service": what the code after it means
The App Service deploy tasks (AzureRmWebAppDeployment@4 and @5, AzureWebApp@1, and the Azure Functions deploy tasks) upload the package to the app's deployment service, Kudu, on the scm site (https://<app>.scm.azurewebsites.net). When the upload fails, the task writes this sentence and adds what came back: the scm site's HTTP status, written as Conflict (CODE: 409), or the message of a network error when the agent could not reach the site. The sentence is the same for every cause, so the part after it is the clue (a Stack Overflow question on it has been seen over 44,000 times).
When the deploy runs in a pull request's build validation, the required build stays failed until a deploy goes through: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once the pipeline is fixed. Get it on JetBrains Marketplace
What it looks like
##[error]Error: Failed to deploy web package to App Service. Conflict (CODE: 409). Other endings:Internal Server Error (CODE: 500),Bad Request (CODE: 400),Ip Forbidden (CODE: 403),getaddrinfo ENOTFOUND <app>.scm.azurewebsites.net,connect ETIMEDOUT.- The task's library builds the ending from the response as
<status text> (CODE: <number>); the reason the scm site gave is in the response body, which is not shown. Set the variablesystem.debugtotrueand run again: the log then has the whole ZIP Deploy response.
Conflict (CODE: 409)
- Kudu's source (the version for App Service on Windows) answers 409 to a zip deploy in three cases: another deployment is already running on the app, an auto swap is going on, or the app is set to run from a package at a remote URL, in which case Kudu says deployment is not supported in that configuration.
- For the first two, wait and run again, and do not let two stages or pipelines deploy to the same app or slot at the same time. For the third, remove the remote package URL from the app settings, or deploy by changing that URL instead.
- On the most read 409 question, Microsoft support found the App Service plan at the limits of the Free tier, and a paid tier fixed it (the accepted answer). The most voted answer there restarted the app.
Internal Server Error (CODE: 500) or Bad Request (CODE: 400)
- These point at the app's side. On the most read 500 question, the cause was a source control connection set up earlier in the app's Deployment Center: even after it was removed, a leftover
deploymentsfolder in Kudu broke the deploy, and deleting that folder fixed it (the accepted answer). On the first question above, an answer fixed it by selecting Disconnect in Deployment Center. - A full disk gives the same result. Open the app's Advanced Tools (Kudu) and look at the disk use; other answers point to running out of space (a 400 question).
Ip Forbidden (CODE: 403), ENOTFOUND or ETIMEDOUT: the agent cannot reach the scm site
- A private endpoint cuts the app off from the internet, and Microsoft-hosted agents connect from public addresses. Run the deploy on a self-hosted agent (a VM or a scale set) in the virtual network that can reach the private endpoint (the accepted answer on a 403 question).
- Access restrictions apply to the scm site as well. It has its own list, Advanced tool site, which can also use the main site's rules (Microsoft's page on access restrictions). If you limit the main site, the deploying agent needs to be allowed on the scm site.
getaddrinfo ENOTFOUNDmeans the agent could not look up<app>.scm.azurewebsites.net: with a private endpoint, the agent has to use the private DNS zone. In a classic release, also check Run on agent: on one question, the agent pool of a new release had changed, and selecting the right pool fixed it.
ERROR_FILE_IN_USE with Web Deploy
- With Deployment method set to Web Deploy, the failure looks different: Web Deploy cannot replace a file the running app holds. Rename locked files and Take App Offline are on by default and do not always help; Microsoft support told one asker that renaming works only for DLLs, and
-useChecksumin Additional arguments fixed it (the accepted answer). - The task itself suggests Run From Package for this: the app runs from the zip, so no files are replaced in place. It does not take MSBuild packages.
Azure DevOps pull requests in IntelliJ IDEA and Rider
Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps, Azure Pipelines and Azure App Service are trademarks of Microsoft Corporation; GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, GitHub, Inc. or JetBrains.
More: the dotnet task matched no project · no zip where the deploy task looks · no template, or no parameters file · a resource authorization issue · 日本語