Minimize restarts: Changing app settings in a production slot requires a restart of the running app.If the changes swapped into the production slot aren't as you expect, you can immediately reverse the swap to get your 'last known good instance' back. Easy fallbacks: After a swap with production, the slot with a previously staged app now has the previous production app.Instances are warmed up before deployment, which reduces the cold start for newly deployed functions. Additionally, using slots reduces latency for HTTP-triggered workloads. Prewarming: Deploying to a slot instead of directly to production allows the app to warm up before going live.Different environments for different purposes: Using different slots gives you the opportunity to differentiate app instances before swapping to production or a staging slot.There are many advantages to using deployment slots, including: To learn how to write stateless and defensive functions, see Improve the performance and reliability of Azure Functions. Currently executing function are terminated during the swap.This seamless behavior occurs because the next function trigger is routed to the swapped slot. Traffic redirection is seamless no requests are dropped because of a swap.

The following reflect how functions are affected by swapping slots: For more information, see Service limits. You can obtain more staging slots by running your app in a Premium plan or Dedicated (App Service) plan. Function apps running in a Consumption plan have a single extra slot for staging. One app instance is always mapped to the production slot, and you can swap instances assigned to a slot on demand. Slots are different environments exposed via a publicly available endpoint.

Azure Functions deployment slots allow your function app to run different instances called slots.

Azure web app deployment slots