Web App (Linux): Deployment Slots Swap Causes Traffic to Precede Startup Signal

Dylan-0612 0 Reputation points
2026-11-06T16:12:10.7233333+00:00

Problem description

I am experiencing an issue where, during deployment slot swaps in my Azure Web App (Linux), traffic begins before the startup signal is issued. This results in some instances serving traffic prematurely, which is causing errors and inconsistent behavior. I need assistance understanding why this is happening and how to prevent traffic from starting before the startup signal.

Environment

Azure Web App (Linux), Deployment slots, Region not specified in the case information.

What I've already tried

I have reviewed the latest case communication and logs, but I have not tried any troubleshooting steps myself yet.

Current status

I am seeking guidance on the cause of this behavior and how to ensure traffic only begins after the startup signal during slot swaps.

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Sedat SALMAN 14,535 Reputation points MVP
    2026-11-07T17:41:15.2866667+00:00

    The swap only waits on the warm-up request, and by default any HTTP response code counts as a valid warm-up. An instance that answers with an error can therefore be treated as ready. To tighten this on Linux, use the swap warm-up app settings, since applicationInitialization is a Web.config element.

    1. On the slot you swap from, add WEBSITE_SWAP_WARMUP_PING_PATH with a path that only succeeds once your app is truly ready, for example /statuscheck.
    2. Add WEBSITE_SWAP_WARMUP_PING_STATUSES with 200,202 so any other code stops the warm-up and the swap.
    3. Optionally add WEBSITE_WARMUP_PATH so the same path is also pinged on every restart, not only on swaps.

    If errors continue, tell me which path your app serves for health and what the failing requests return.

    References:

    If this solved it, please click Accept Answer and upvote so others with the same problem can find it.

    Was this answer helpful?

    0 comments
  2. kagiyama yutaka 5,755 Reputation points
    2026-11-08T02:21:29.0233333+00:00

    I think the first check is whether those early requests actually hit production. The staging slot has its own live hostname, so compare request hosts and per-instance timestamps with the swap activity log. On the source slot, make /ready return 503 until initialization finishes, then 200. Set WEBSITE_SWAP_WARMUP_PING_PATH=/ready and WEBSITE_SWAP_WARMUP_PING_STATUSES=200.

    Use swap with preview to test readiness after production settings are applied, before completing the swap.

    Was this answer helpful?

    0 comments

Your answer

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