MSDN Community Discussions

Trouble with Azure Functions Deployment Slot Switching

Hi everyone,

I'm encountering an issue when trying to swap deployment slots for my Azure Function. I have a 'staging' slot and a 'production' slot. When I initiate a swap from staging to production, the swap completes without errors, but the production slot doesn't seem to pick up the new code immediately. It appears to be stuck on the old version for a few minutes, and then it suddenly starts serving the new code.

Is this expected behavior? Or is there a common configuration I might be missing that causes this delay?

Specifically, I'm using a deployment pipeline with Azure DevOps. The function is written in C#.

Any insights would be greatly appreciated!

Thanks,

John

Hey John,

This behavior can sometimes happen due to various factors, including application initialization time and potential health checks. When you swap slots, Azure doesn't instantly cut over traffic. It performs a phased approach:

• The new code is deployed to the production slot.
• Azure waits for the application to warm up and become ready.
• If you have auto-swap or specific health check configurations, it might wait for those to pass.
• Only then is traffic directed to the new version.

For Azure Functions, especially those with dependencies or longer startup times, a delay isn't entirely uncommon. Are you seeing any specific errors in the Function App logs during or after the swap?

You might want to check your Function App's diagnostic settings and Kudu logs for any clues. Also, ensure your app settings are correctly configured for the production slot. Sometimes, a missing or incorrect connection string can cause startup issues.

If you're using custom startup logic or a specific trigger that might take time to initialize, that could also contribute to the delay.

Let us know if you find anything in the logs!

Hi John, Alice,

I experienced something similar a few months back. For me, it turned out to be related to how the `FUNCTIONS_WORKER_RUNTIME` setting was handled during the swap. Ensure it's explicitly set in your application settings for both slots, and that it matches your actual runtime (e.g., `dotnet`, `node`, `python`).

Also, check your deployment pipeline. Sometimes, a task might be incorrectly configured, leading to a delayed start or an incomplete deployment of all necessary files.

Another thing to consider is the 'Always On' setting for your Function App. While typically enabled for production, if it's disabled for the production slot or not configured correctly, it might lead to cold starts after a swap.

You can also test the swap manually via the Azure portal to see if the behavior differs from your automated pipeline.

Thanks for the quick replies, Alice and Robert!

Alice, I checked the logs, and I'm not seeing any explicit errors related to the swap itself. However, I did notice a slight increase in the application initialization time reported in some custom metrics I have. I'll look closer into the health check configurations.

Robert, that's a great point about `FUNCTIONS_WORKER_RUNTIME`. I'll verify that it's correctly set in both slots. The 'Always On' setting is indeed enabled for production. I will also try the manual swap via the portal to compare.

I'll report back once I've investigated these points further.

Cheers,

John