What happens to in-flight API requests during Azure App Service deployment slot swaps?

Edgar 20 Reputation points
2025-03-20T23:17:50.9933333+00:00

I'm working on migrating our company's web application from VM-based infrastructure to Azure PaaS solutions, particularly using Azure App Service for our API layer. I'm very interested in the zero-downtime deployment capabilities of deployment slots.

The documentation clearly states that "traffic redirection is seamless" but I'm looking for more specific details on what happens to in-flight requests (especially POST requests) at the exact moment a slot swap occurs.

For example:

  • If a client has sent a POST request and it's being processed when the deployment slot swap happens, what happens to that request?
  • If a client's request is en route to API and it swaps before the request arrives, does this request get delivered to the new slot?
  • Does the original slot complete all in-flight requests before the DNS routing changes?
  • Are there any edge cases where a client might need to retry their request?

I'd really appreciate hearing from anyone with practical experience or deeper technical knowledge on this specific aspect of Azure App Service slot swaps. Has anyone encountered issues with in-flight requests during swaps or can you confirm they're handled gracefully?

Thanks in advance for any insights!

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
8,961 questions
0 comments No comments
{count} votes

Accepted answer
  1. Bhargavi Naragani 6,055 Reputation points Microsoft External Staff Moderator
    2025-03-21T00:24:03.5433333+00:00

    Hi @Edgar,

    During an Azure App Service deployment slot swap, the handling of in-flight API requests is designed to minimize disruption. Here are the key points regarding what happens to in-flight requests:

    1. If a client has sent a POST request and it is being processed when the swap occurs, that request will typically be completed by the original slot before the swap is finalized. The swap operation ensures that the target slot remains online while the source slot is prepared, which helps in completing ongoing requests.
    2. If a client's request is en route to the API and the swap occurs before the request arrives, the request will be delivered to the new slot. The routing rules are switched only after the source slot has completed its preparation and is ready to handle requests.
    3. The original slot is expected to complete all in-flight requests before the DNS routing changes. This is part of the design to ensure that users experience minimal disruption.
    4. There may be edge cases where a client might need to retry their request, especially if the swap operation encounters issues or if there are transient connection failures during the swap. Implementing client-side retry logic can help mitigate these situations.

    Overall, Azure App Service aims to handle slot swaps gracefully to ensure that ongoing requests are processed without interruption.

    Kindly refer to the below documentations for better understanding:
    Set up staging environments in Azure App Service
    Azure Functions deployment slots

    If the answer is helpful, please click Accept Answer and kindly upvote it so that other people who faces similar issue may get benefitted from it.

    Let me know if you have any further Queries.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.