Azure App Service Slot Swaps Causing Restarts

Question

Azure App Service Slot Swaps Causing Restarts

Bray Modal 0

We have a .NET Core 9 app for which we have set up a staging slot. Both the "production" and "staging" slots have the same app settings. We additionally added "WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1" and "WEBSITE_SKIP_ALL_BINDINGS_IN_APPHOST_CONFIG=1" as suggested by different articles. However, whenever we do a swap, the apps restart and defeat the whole purpose of having a staging slot. What else could be causing the apps to restart?

2 answers

Your answer

Answer 1

Shree Hima Bindu Maganti 6,660 Microsoft External Staff Moderator

Hi @Bray Modal
I see you’re experiencing restarts when swapping your Azure App Service slots.

Swapping slots can trigger application restarts due to factors like hostname binding changes, socket state, or resource state even if app settings are the same. Common causes include user-initiated restarts, configuration changes, slot-specific settings, scaling, or Azure maintenance.

Use the Diagnose and solve problems blade in the Azure portal and run the Web App Restarted detector to find out why and when restarts occur.

Implementing health checks can help Azure determine if your app is ready for requests, especially if it relies on external dependencies that need time to load.

Make sure settings like WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 and WEBSITE_SKIP_ALL_BINDINGS_IN_APPHOST_CONFIG=1 are set in all slots to avoid binding conflicts.

Storage events or discrepancies after a swap can cause worker process restarts. Check that your app responds to health checks and HTTP pings before and after swaps, and review eventlog.xml in D:\home\LogFiles\ for errors that might explain the restarts.
Set up staging environments in Azure App Service

Diagnose web app restarts

Health check in Azure App Service
Let me know if you have any further assistances needed.

Bray Modal 0 Reputation points

2026-01-19T21:43:46.88+00:00

We created the app service and slot with ARM templates and gave them identical configurations and did not use slot-settings, custom domains, or network settings to avoid needing a restart. Essentially, the only difference between them would be the app build and of course the host name. We see no errors in the logs, just info logs for shutdown/startup.

As documentation claims, '"No requests are dropped because of swap operations". That is our end-goal, but if the old "prod" app that is still serving requests is restarted, that is not a true statement.
Shree Hima Bindu Maganti 6,660 Reputation points Microsoft External Staff Moderator

2026-01-22T06:21:48.42+00:00

Hi @Bray Modal
This behavior is expected in Azure App Service. Even when production and staging slots are created using identical ARM templates and no slot-specific settings, a slot swap requires the platform to update the hostname-to-content mapping and activate the new application binaries, which results in a graceful worker process recycle. The documentation statement that “no requests are dropped” refers to Azure’s front-end traffic management, which continues to accept and route requests during the swap, not to uninterrupted execution of the same application process. When health checks and graceful shutdown are properly configured, in-flight requests are allowed to complete and new requests are routed only after the swapped slot is ready. Therefore, the observed shutdown and startup logs are by design and do not indicate request loss or misconfiguration.
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs
Let me know if you have any further assistances needed.

Answer 2

Michele Ariis 7,205 MVP

Hi, slot swaps on App Service are never truly “no restart”. A swap replaces the site’s configuration and content mapping under the hood, so the worker process gets recycled. Those two WEBSITE_APPHOST_CONFIG settings only affect IIS/hosting bindings behavior and don’t prevent a recycle.

What you can do is minimize the impact: make sure all settings that should not change are marked as slot settings, avoid swapping anything that forces config reload (connection strings, identity settings, auth settings), and use “swap with preview” to warm up the target slot before completing the swap. But a process recycle during swap is expected behavior on App Service, so the goal is “no downtime” via warmup, not “no restart”.

Bray Modal 0 Reputation points

2026-01-19T21:11:09.1733333+00:00

I feel as though "no restart" is somewhat an inherited expectation of "no downtime". From documentation at https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal, "You can make sure that all instances of the slot are warmed up before you swap it into production. This approach eliminates downtime when you deploy your app. The traffic redirection is seamless. No requests are dropped because of swap operations."

From this we can assume "eliminates downtime" means any client calling during the swap is served. From "No requests are dropped because of swap operations", I take as all requests before, during, and after the swap are served and not dropped. So, I think it would be reasonable to expect no restart on the "old" app once it's moved to the staging slot. But that is not what we are seeing. Any active requests on "prod" slot are dropped and return a 502 error after it is moved to the staging slot due to the restart/recycle

Share via

Azure App Service Slot Swaps Causing Restarts

2 answers

Your answer