Troubleshoot HTTP error of “502 bad gateway” and “503 service unavailable” in Azure App Service

In this article, you will find the steps on how to troubleshoot HTTP “502 Bad Gateway” error or a HTTP “503 Service unavailable” error.

The most common causes for this behavior are:

• Requests taking a long time to execute.
• Application using high memory/CPU.
• Application crashing due to an exception.

Observe and monitor the application behavior

Monitor the application, using the Azure portal and the Diagnose and Solve problems blade. Some of the metrics that you might want to monitor for your application are:

• Average memory working set
• Average response time
• CPU time
• Memory working set
• Requests

Collect Data

1. Use the Diagnostics tools: App Service provides the option to troubleshoot with no configuration required. When you do run into issues with your app, the diagnostics tool will point out what’s wrong to guide you to the right information to troubleshoot and resolve the issue more easily and quickly.

    1. Go to Azure Portal
    2. Go to  the application 
    3. Navigate in the left menu to Diagnose and solve problems.
   

2. Using the Kudu App Service comes with a debug console that you can use for debugging, exploring, uploading files, as well as JSON endpoints for getting information about your environment. This is called the Kudu Console or the SCM Dashboard for your app. You can access this dashboard by going to the link https://<Your app name>.scm.azurewebsites.net

Some of the things that Kudu provides are

• Environment settings for your application
• Log stream
• Diagnostic dumps
• Debug console in which you can run Powershell cmdlets and basic DOS commands.

Mitigate the issue

• Scale the App: In Azure App Service, for increased performance and throughput, you can adjust the scale at which you are running your application. Scaling up an app involves two related actions: changing your App Service plan to a higher pricing tier and configuring certain settings after you have switched to the higher pricing tier. Additionally, you can choose to run your application on more than one instance. This not only provides you with more processing capability, but also gives you some amount of fault tolerance. If the process goes down on one instance, the other instance will continue serving requests.

• Use AutoHeal: AutoHeal recycles the worker process for your app based on settings you choose (like configuration changes, requests,memory-based limits, or the time needed to execute a request). Most of the time, recycle the process is the fastest way to recover from a problem. Though you can always restart the app from directly within the Azure Portal, AutoHeal will do it automatically for you. All you need to do is add some triggers in the root web.config for your app. Note that these settings would work in the same way even if your application is not a .NET one.