Troubleshooting Azure App Service Apps Using Web Server Logs

Microsoft

Apr 01, 2019

First published on MSDN on Jun 22, 2016

Oftentimes, the best way to start troubleshooting a web application is to check the web server logs. Web servers log each request that they process, and by checking the server logs, you can often find out details about why things went wrong. Particularly, you want to pay attention to a couple of different fields in the log file; the HTTP status code and the HTTP sub-status code. In your server logs, these are labeled as sc-status and sc-substatus .

Please keep in mind that requests are not immediately added to your web server logs. It may take a couple of minutes between the time a request is made and the time that it makes it into your server logs.

Note: For information about enabling diagnostic logs and downloading logs in Azure App Service, see Enable Diagnostics Logging for Web Apps in Azure App Service . This documentation is useful for enabling, downloading and analyzing all of the different diagnostic logs mentioned in this post.

HTTP Status Classes

The first digit of an HTTP status code indicates the class of the status code. You can get a general idea of what a particular entry in your web server logs means by the class. The following outlines the various HTTP status code classes.

1 (Status codes 1xx) - Informational messages indicating that a request was received and is processing.
2 (Status codes 2xx) - A successful request. The web server understood the request and processed it.
3 (Status codes 3xx) - The client (usually a web browser) needs to take additional action in order to complete the request. (This is often a redirection, but not always.)
4 (Status codes 4xx) - An error from the client prevented the request from being processed.
5 (Status codes 5xx) - The request was valid, but a problem at the server prevented the request from succeeding.

Now that you know the various HTTP status classes, let's look at some of the more common HTTP status codes you might see in a Web App running in Azure App Service. I'll skip the class 1 and class 2 status codes since they are informational or successful.

Class 3 Status Codes

A class 3 status code means that the client must take additional action in order to complete the request. The following class 3 status codes might appear in your web server logs.

Status	Sub-Status	Description
301	N/A	Moved Permanently – Typically used when a URI changes due to a site redesign and so forth. When a search engine crawler encounters this status, it will usually force an update of the URI for the search engine index as well.
302	N/A	Object Moved – Used when a redirect is required for purposes of logging a user in, temporarily redirecting a URI, etc.
304	N/A	Not Modified – Indicates that the URI requested has not been modified since the client last requested it. This will usually mean that the client uses a cached copy of the resource.
307	N/A	Temporary Redirect – Similar to a 302 redirect, but a 307 redirect does not allow the client to change the HTTP method used to request the resource.

Class 4 Status Codes

A class 4 status code means an error from the client prevented the request from being processed. The following class 4 status codes might appear in your web server logs.

Note: There are some cases where you can see a 403 status in the browser, but no 403 events are logged in the HTTP server logs. For example, if your Web App is stopped, you will see a 403 error in the browser telling you the site is stopped, but you won’t see a 403 in the server logs. If your site is disabled due to a quota violation, that will also show a 403 in the browser without a corresponding entry in the server logs. For more information on troubleshooting 403 errors, see the Web Apps support team blog .

Status	Sub-Status	Description
400	0	Bad Request – The client sent a request that was unrecognized by the server or that was badly formed and rejected. It is often helpful to review Failed Request Tracing to get more details on any 400 error, regardless of sub-status. A 400 HTTP status means that the client did not send a good request to the server.
400	6	Invalid Request Body
400	7	Invalid Content Length
401	0	Unauthorized – The web app requires an authenticated user and the user was not authenticated. When a 401 occurs, you will typically see a sub-status that will give you more information. Refer to the following sub-status codes.
401	1	Logon Failure – The request contained credentials but they were not accepted by the authentication provider. This is typically caused by an incorrect username and/or password or a user who doesn’t have permission to access the resource.
401	2	Logon Config – This is caused by a problem in the authentication settings on the server. In Web Apps, this would likely be returned by an authentication module on the server. Checking Failed Request Tracing logs to see which module set the 401.2 status would be advised.
401	3	Logon ACL – The user did successfully authenticate, but the user does not have permissions to access the resource. Check to ensure that the user has been given permission. For example, if you are using Azure Active Directory authentication, ensure that the user has been given permission in Azure Active Directory.
401	7	URL Auth Policy – The user was denied access to the specific URL due to URL Authorization. For more information on this feature, see this . For information on URL authorization with ASP.NET, see this .
401	501	The request was denied by Dynamic IP Restriction . In this case, the client made too many concurrent requests. (For information on configuring Dynamic IP Restrictions in Web Apps, see this .)
401	502	The request was denied by Dynamic IP Restriction . In this case, the client exceeded the allowed request rate. (For information on configuring Dynamic IP Restrictions in Web Apps, see this .)
401	503	The request was denied by IP Restriction because the source IP address is not allowed. (For information on configuring IP Restriction in Web Apps, see this .)
401	504	The request was denied by IP Restriction because the source host name is not allowed. (For information on configuring IP Restriction in Web Apps, see this .)
403	0	Forbidden – The request was forbidden for some reason. Without a sub-status code, the best way to dig further would be to use Failed Request Tracing .
403	4	SSL Required – The request was made without SSL, but the resource is configured to require SSL. Use HTTPS instead of HTTP.
403	14	Directory Listing Denied – A URI was used that did not specify a document name and no default document is configured. See the Azure documentation on configuring a default document for your Web App.
403	501	The request was denied by Dynamic IP Restriction . In this case, the client made too many concurrent requests. (For information on configuring Dynamic IP Restrictions in Web Apps, see this .)
403	502	The request was denied by Dynamic IP Restriction . In this case, the client exceeded the allowed request rate. (For information on configuring Dynamic IP Restrictions in Web Apps, see this .)
403	503	The request was denied by IP Restriction because the source IP address is not allowed. (For information on configuring IP Restriction in Web Apps, see this .)
403	504	The request was denied by IP Restriction because the source host name is not allowed. (For information on configuring IP Restriction in Web Apps, see this .)
404	0	Not Found – A request was made for a resource that was not found on the server. This is typically a request to a non-existent file.
404	5	URL Sequence Denied – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	6	Verb Denied - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	7	File Extension Denied - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	8	Hidden Segment - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	10	Request Header Too Long - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	11	URL Double Escaped - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	12	URL Has High Bit Characters - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	13	Content Length Too Large - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	14	URL Too Long - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	15	Query String Too Long - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	18	Query String Sequence Denied - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	19	Denied by Filtering Rule - The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information.
404	501	The request was denied by Dynamic IP Restriction . In this case, the client made too many concurrent requests. (For information on configuring Dynamic IP Restrictions in Web Apps, see this .)
404	502	The request was denied by Dynamic IP Restriction . In this case, the client exceeded the allowed request rate. (For information on configuring Dynamic IP Restrictions in Web Apps, see this .)
404	503	The request was denied by IP Restriction because the source IP address is not allowed. (For information on configuring IP Restriction in Web Apps, see this .)
404	504	The request was denied by IP Restriction because the source host name is not allowed. (For information on configuring IP Restriction in Web Apps, see this .)

Class 5 Status Codes

A class 5 status code means the request was valid, but a problem at the server prevented it from completing. The following class 5 status codes might appear in your web server logs.

Status	Sub-Status	Description
500	0	Internal Server Error – Typically caused by an error in server-side code. If using Internet Explorer, it is often helpful to turn off Friendly HTTP Error Messages to get more information. You may also want to troubleshoot such errors with Visual Studio. See Troubleshoot a Web App in Azure App Service Using Visual Studio for more information.
500	50	URL Rewrite Error – Error in inbound rule or a configuration error in URL Rewrite. For more information, see the documentation on URL Rewrite .
500	51	URL Rewrite Error – Global configuration or global rules execution error occurred. For more information, see the documentation on URL Rewrite .
500	52	URL Rewrite Error – Outbound rule error occurred. For more information, see the documentation on URL Rewrite .
500	53	URL Rewrite Error – Outbound rule error occurred. The rule is configured to execute before outbound cache gets updated. For more information, see the documentation on URL Rewrite .
500	121	The request was timed out by Azure App Service. Azure App Service will timeout any request that executes for 230 seconds without sending a response. If you encounter this, the solution is to troubleshoot the slow request .
502	N/A	Server received an invalid response while acting as a gateway or proxy. This status may be shown in a browser, but you may not see an entry in your logs. This actually may be caused by your application crashing when a request is received. You can often find details by parsing the eventlog.xml file . To troubleshoot this, see our documentation on troubleshooting these issues .
503	0	Server Unavailable – This is often caused by an application issue, often a crash in your application. Your best bet for tracking that down is to follow our troubleshooting steps on these errors.