Azure Function App Deploy Fails – 3 Fixes That Work

1. Wrong SCM Endpoint – The Real Culprit

Almost every time I see a failed Azure Function App deployment, it's because the deployment tool is pointing to the wrong SCM endpoint. You're using the .scm.azurewebsites.net URL, right? But here's the catch – if your function app is in a deployment slot, the SCM URL isn't the same as the main app's.

Example: your function app is myfunctionapp-prod. The SCM URL for the production slot is myfunctionapp-prod.scm.azurewebsites.net. But if you're deploying to a staging slot called staging, the correct SCM URL is myfunctionapp-prod-staging.scm.azurewebsites.net. That dash before the slot name trips people up.

Fix it:

# In Azure DevOps – Use the SCM endpoint variable from the task
# Or set it manually in your pipeline
scmEndpoint: 'https://$(functionAppName)-$(slotName).scm.azurewebsites.net'

If you're using the Azure CLI, run az functionapp deployment source config-zip with the --slot parameter. Without it, it defaults to the production slot. That'll give you a 401 or a 404 error every time.

One more thing – sometimes the SCM endpoint is just down for a minute. If you get a 503 Service Unavailable, wait 30 seconds and try again. It's not your code, it's Azure's load balancer hiccuping.

2. Stale Kudu Cache – It Bites You After an Update

Your function app was working fine yesterday. You pushed a small change, and now deployment fails with a 500 Internal Server Error from Kudu. The culprit is almost always a stale cache in the Kudu runtime.

Kudu (the engine behind the SCM endpoint) caches your function app's metadata. When you change your function bindings or add a new package reference, Kudu doesn't always pick up the changes immediately. The deployment looks like it succeeded, but your function app still runs the old code.

Fix it:
Clear the Kudu cache manually. Use the Azure portal or curl:

curl -X DELETE https://myfunctionapp.scm.azurewebsites.net/api/processes

This kills all running processes in Kudu. It's safe – Azure will restart them. Then redeploy. I've fixed at least 20 tickets with this one command.

Don't bother restarting the function app from the Azure portal. That only restarts the main worker process, not Kudu. You need to hit the SCM endpoint directly.

If you're using a CI/CD pipeline, add a step to call this API before every deployment. Saves you the headache of debugging a “successful” deployment that doesn't work.

3. Corrupted Deployment Package – Windows vs Linux Runtime

This one is sneaky. You build your function app on a Windows dev machine, then deploy to a Linux consumption plan. The zip package includes node_modules or bin folders with Windows-specific symlinks. Azure's Linux runtime can't read them, and deployment fails with ERROR_FILE_IN_USE or a generic 500.

Fix it:
Always build your deployment package on the same OS as your target runtime. If you're using Azure DevOps, set the Agent Specification to ubuntu-latest for a Linux function app. If you're deploying from your local machine, use WSL or a Linux build agent.

Here's a quick check – open your zip file and look for node_modules/.bin files. If you see .cmd files, that's Windows-specific. Delete them before zipping.

# In your build pipeline – clean up Windows artifacts
find . -name '*.cmd' -delete
zip -r deployment.zip . -x '*.git*' '*.cmd'

Also, check your host.json file. A missing or malformed version field can cause a silent fail. Make sure it has "version": "2.0" – the runtime reads this first.

Quick-Reference Summary Table

I've seen these three issues cover about 90% of function app deployment failures. Start with #1, then #2. If those don't work, check your build environment. And remember – the SCM endpoint is your best friend. Learn to love it.