App service encountering 499 status codes occasionally (and the UX is ruined when it does happen)

Arya + 0 Reputation points
2025-03-13T18:26:21.3766667+00:00

Screenshot 2025-03-13 121321.png

Having trouble tracking down semi frequent 499 errors in my app service. I attached a screenshot of some example requests. I enabled the "Always On" feature for the app service which sends a GET request to / every 5 minutes. This ping is occasionally encountering a 499 status code response. This is causing issues, because our web app is being embedded into another view via an iframe (the embedding logic is out of our control). If the embed logic encounters a non success response, it will show a default fallback view.

  1. We'd like to understand why we get the 499 (we have read the docs already and know that its due to the client terminating the request before the server is able to respond). In the case where its the "Always On" encountering the error, who is the "client"? Is there some kind of load balancer or application gateway in front of the app service and that is the client that is returning the 499?
  2. We need to either eliminate the 499 errors or work around them somehow, as it completely ruins the end user experience when a 4xx status code is received.

Thanks!

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

1 answer

Sort by: Most helpful
  1. hossein jalilian 10,340 Reputation points
    2025-03-13T20:05:55.29+00:00

    Thanks for posting your question in the Microsoft Q&A forum.

    The Azure's internal health check system, which sends periodic requests to keep your app loaded. When these requests fail with 499, it indicates Azure's infrastructure is terminating the connection before your app responds, usually due to:

    Cold start delays exceeding timeout thresholds

    Resource constraints during app initialization

    Timeout mismatches in intermediary services (Application Gateway/Load Balancer)

    Check which components exist in your architecture using:

    az webapp show --name <app-name> --resource-group <rg-name> --query "siteConfig"
    
    

    Extend Application Gateway Timeouts

    az network application-gateway probe update \
      --gateway-name <gateway-name> \
      --resource-group <rg-group> \
      --name <probe-name> \
      --timeout 120
    

    Adjust Health Check Endpoint:

    Create a lightweight dedicated endpoint for Always On checks

    [Route("healthcheck")]
    public IActionResult HealthCheck() => Content("OK"); 
    
    

    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is 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.