Troubleshoot HTTP error of “502 bad gateway” and “503 service unavailable” in Azure App Service
Sometimes, you will face “502 bad gateway” and “503 service unavailable”, these are common errors in your app or apps hosted in Azure App Service. In this article we recommend some troubleshooting steps you can follow on your own to try to identify the issue or gather useful information before reaching out for support.
When you browse to the app, it returns a 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.
So, to troubleshoot these errors, you can follow the next steps which will be divided in 3 distinct tasks, in sequential order:
Observe and monitor the application behavior:
- Track the Service Health: The first step you can do is checking the service health. Microsoft Azure publicizes each time there is a service interruption or performance degradation. You can track the health of the service on the Azure Portal. For more information, see Track service health.
- Monitor your application: You can monitor your application using the Azure Portal and going to Diagnose and Solve Problems blade where you will find different options to check the performance of your application, as shown below:
You can also check the metrics blade. Some of the metrics that you might want to monitor for your app are:
Average memory working set.
Average response time.
Memory working set.
For more information, see:
- Use the Diagnostics Tools: App Service provides an intelligent and interactive experience to help you troubleshoot your app 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. To access App Service diagnostics, navigate to your App Service app or App Service Environment in the Azure portal. In the left navigation, click on Diagnose and solve problems. As shown below:
- Use the KUDU debug console: 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/.
Also, you can look for KUDU directly from the Azure Portal as shown below:
Some of the things that Kudu provides are:
Environment settings for your application
Debug console in which you can run Powershell cmdlets and basic DOS commands.
Another useful feature of Kudu is that in case your application is throwing first-chance exceptions, you can use Kudu and the SysInternals tool Procdump to create memory dumps. These memory dumps are snapshots of the process and can often help you troubleshoot more complicated issues with your app.
For more information on features available in Kudu, see Azure Websites online tools you should know about.
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.
You can set the scaling to be Manual or Automatic.
For more information on scaling, see Scale an app in Azure App Service.
- 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.
For more information, see Auto-Healing Azure Web Sites.
- Restart the application: This is often the simplest way to recover from one-time issues. On the Azure Portal, on your app’s blade, you have the options to stop or restart your app.
By following all these steps, you can perform some self-troubleshooting before reaching out to support and having this information will be very helpful to keep digging deeper into the real root cause.