For our Azure function we use the auto-slot-swapping feature with the following appsettings to ensure our slot is warmed before going live:
WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS = 1
WEBSITE_SWAP_WARMUP_PING_PATH = "/api/healthcheck"
WEBSITE_SWAP_WARMUP_PING_STATUSES = "200"
This results in our ADO pipeline calling the healthcheck endpoint (confirmed), and only swapping the slot to live if it's successful.
The problem is that after all this takes place, there's a wait of many seconds to a request before we receive a response. Any request thereafter is virtually instant. This behaviour is consistent for every deploy.
We would not expect this, because we know the Staging slot is warmed when the healthcheck endpoint is hit, before the slot is then swapped into Production. So why do we experience this cold start delay? We can even wait a minute or two after the slot swapping has completed, and we always experience it.
Is there something odd happening, like once the slot is moved into Production, it needs to be hit again before it's warmed?
This may help you.
After slot swaps, the app may experience unexpected restarts. This is because after a swap, the hostname binding configuration goes out of sync, which by itself doesn’t cause restarts. However, certain underlying storage events (such as storage volume failovers) may detect these discrepancies and force all worker processes to restart. To minimize these types of restarts, set the WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 app setting on all slots
If you set variable WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to 1 you should be able to get rid of cold starts, which are caused be restarting host machine. However, please be aware that during slot function may process requests very slowly.
You may also check this github issue where you find a discussion about zero downtime deployment.