Enable diagnostics logging for web apps in Azure App Service


Azure provides built-in diagnostics to assist with debugging an App Service web app. In this article, you learn how to enable diagnostic logging and add instrumentation to your application, as well as how to access the information logged by Azure.

This article uses the Azure portal and Azure CLI to work with diagnostic logs. For information on working with diagnostic logs using Visual Studio, see Troubleshooting Azure in Visual Studio.


Although this article refers to web apps, it also applies to API apps and mobile apps.

Web server diagnostics and application diagnostics

App Service web apps provide diagnostic functionality for logging information from both the web server and the web application. These are logically separated into web server diagnostics and application diagnostics.

Web server diagnostics

You can enable or disable the following kinds of logs:

  • Detailed Error Logging - Detailed error information for HTTP status codes that indicate a failure (status code 400 or greater). It may contain information that can help determine why the server returned the error code.
  • Failed Request Tracing - Detailed information on failed requests, including a trace of the IIS components used to process the request and the time taken in each component. It is useful if you are attempting to increase site performance or isolate what is causing a specific HTTP error to be returned.
  • Web Server Logging - Information about HTTP transactions using the W3C extended log file format. It is useful when determining overall site metrics such as the number of requests handled or how many requests are from a specific IP address.

Application diagnostics

Application diagnostics allows you to capture information produced by a web application. ASP.NET applications can use the System.Diagnostics.Trace class to log information to the application diagnostics log. For example:

System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");

At runtime, you can retrieve these logs to help with troubleshooting. For more information, see Troubleshooting Azure web apps in Visual Studio.

App Service web apps also log deployment information when you publish content to a web app. It happens automatically and there are no configuration settings for deployment logging. Deployment logging allows you to determine why a deployment failed. For example, if you are using a custom deployment script, you might use deployment logging to determine why the script is failing.

How to enable diagnostics

To enable diagnostics in the Azure portal, go to the page for your web app and click Settings > Diagnostics logs.

Logs part

When you enable application diagnostics, you also choose the Level. This setting allows you to filter the information captured to informational, warning, or error information. Setting it to verbose logs all information produced by the application.


Unlike changing the web.config file, enabling Application diagnostics or changing diagnostic log levels does not recycle the app domain that the application runs within.

For Application logging, you can turn on the file system option temporarily for debugging purposes. This option turns off automatically in 12 hours. You can also turn on the blob storage option to select a blob container to write logs to.


Currently only .NET application logs can be written to the blob storage. Java, PHP, Node.js, Python application logs can only be stored on the file system (without code modifications to write logs to external storage).

For Web server logging, you can select storage or file system. Selecting storage allows you to select a storage account, and then a blob container that the logs are written to.

If you store logs on the file system, the files can be accessed by FTP, or downloaded as a Zip archive by using Azure CLI.

By default, logs are not automatically deleted (with the exception of Application Logging (Filesystem)). To automatically delete logs, set the Retention Period (Days) field.


If you regenerate your storage account's access keys, you must reset the respective logging configuration to use the updated keys. To do this:

  1. In the Configure tab, set the respective logging feature to Off. Save your setting.
  2. Enable logging to the storage account blob again. Save your setting.

Any combination of file system or blob storage can be enabled at the same time, and have individual log level configurations. For example, you may wish to log errors and warnings to blob storage as a long-term logging solution, while enabling file system logging with a level of verbose.

While both storage locations provide the same basic information for logged events, blob storage logs additional information such as the instance ID, thread ID, and a more granular timestamp (tick format) than logging to file system.


Information stored in blob storage can only be accessed using a storage client or an application that can directly work with these storage systems. For example, Visual Studio 2013 contains a Storage Explorer that can be used to explore blob storage, and HDInsight can access data stored in blob storage. You can also write an application that accesses Azure Storage by using one of the Azure SDKs.

How to: Download logs

Diagnostic information stored to the web app file system can be accessed directly using FTP. It can also be downloaded as a Zip archive using Azure CLI.

The directory structure that the logs are stored in is as follows:

  • Application logs - /LogFiles/Application/. This folder contains one or more text files containing information produced by application logging.
  • Failed Request Traces - /LogFiles/W3SVC#########/. This folder contains an XSL file and one or more XML files. Ensure that you download the XSL file into the same directory as the XML file(s) because the XSL file provides functionality for formatting and filtering the contents of the XML file(s) when viewed in Internet Explorer.
  • Detailed Error Logs - /LogFiles/DetailedErrors/. This folder contains one or more .htm files that provide extensive information for any HTTP errors that have occurred.
  • Web Server Logs - /LogFiles/http/RawLogs. This folder contains one or more text files formatted using the W3C extended log file format.
  • Deployment logs - /LogFiles/Git. This folder contains logs generated by the internal deployment processes used by Azure web apps, as well as logs for Git deployments. You can also find deployment logs under D:\home\site\deployments.


To open an FTP connection to your app's FTP server, see Deploy your app to Azure App Service using FTP/S.

Once connected to your web app's FTP/S server, open the LogFiles folder, where the log files are stored.

Download with Azure CLI

To download the log files using the Azure Command Line Interface, open a new command prompt, PowerShell, Bash, or Terminal session and enter the following command:

az webapp log download --resource-group resourcegroupname --name webappname

This command saves the logs for the web app named 'webappname' to a file named diagnostics.zip in the current directory.


If you have not installed Azure CLI, or have not configured it to use your Azure Subscription, see How to Use Azure CLI.

How to: View logs in Application Insights

Visual Studio Application Insights provides tools for filtering and searching logs, and for correlating the logs with requests and other events.

  1. Add the Application Insights SDK to your project in Visual Studio.
    • In Solution Explorer, right-click your project and choose Add Application Insights. The interface guides you through steps that include creating an Application Insights resource. Learn more
  2. Add the Trace Listener package to your project.
    • Right-click your project and choose Manage NuGet Packages. Select Microsoft.ApplicationInsights.TraceListener Learn more
  3. Upload your project and run it to generate log data.
  4. In the Azure portal, browse to your new Application Insights resource, and open Search. You should see your log data, along with request, usage, and other telemetry. Some telemetry might take a few minutes to arrive: click Refresh. Learn more

Learn more about performance tracking with Application Insights

How to: Stream logs

While developing an application, it is often useful to see logging information in near-real time. You can stream logging information to your development environment using Azure CLI.


Some types of logging buffer write to the log file, which can result in out of order events in the stream. For example, an application log entry that occurs when a user visits a page may be displayed in the stream before the corresponding HTTP log entry for the page request.


Log streaming also streams information written to any text file stored in the D:\home\LogFiles\ folder.

Streaming with Azure CLI

To stream logging information, open a new command prompt, PowerShell, Bash, or Terminal session and enter the following command:

az webapp log tail --name webappname --resource-group myResourceGroup

This command connects to the web app named 'webappname' and begin streaming information to the window as log events occur on the web app. Any information written to files ending in .txt, .log, or .htm that are stored in the /LogFiles directory (d:/home/logfiles) is streamed to the local console.

To filter specific events, such as errors, use the --Filter parameter. For example:

az webapp log tail --name webappname --resource-group myResourceGroup --filter Error

To filter specific log types, such as HTTP, use the --Path parameter. For example:

az webapp log tail --name webappname --resource-group myResourceGroup --path http


If you have not installed Azure CLI, or have not configured it to use your Azure Subscription, see How to Use Azure CLI.

How to: Understand diagnostics logs

Application diagnostics logs

Application diagnostics stores information in a specific format for .NET applications, depending on whether you store logs to the file system or blob storage.

The base set of data stored is the same across both storage types - the date and time the event occurred, the process ID that produced the event, the event type (information, warning, error), and the event message. Using the file system for log storage is useful when you need immediate access to troubleshoot an issue because the log files are updated near instantaneously. Blob storage is use for archival purposes because the files are cached and then flushed to the storage container on a schedule.

File system

Each line logged to the file system or received using streaming is in the following format:

{Date}  PID[{process ID}] {event type/level} {message}

For example, an error event would appear similar to the following sample:

2014-01-30T16:36:59  PID[3096] Error       Fatal error on the page!

Logging to the file system provides the most basic information of the three available methods, providing only the time, process ID, event level, and message.

Blob storage

When logging to blob storage, data is stored in comma-separated values (CSV) format. Additional fields are logged to provide more granular information about the event. The following properties are used for each row in the CSV:

Property name Value/format
Date The date and time that the event occurred
Level Event level (for example, error, warning, information)
ApplicationName The web app name
InstanceId Instance of the web app that the event occurred on
EventTickCount The date and time that the event occurred, in Tick format (greater precision)
EventId The event ID of this event

Defaults to 0 if none specified

Pid Process ID
Tid The thread ID of the thread that produced the event
Message Event detail message

The data stored in a blob would look similar to the following example:

2014-01-30T16:36:52,Error,mywebapp,6ee38a,635266966128818593,0,3096,9,An error occurred


For ASP.NET Core, logging is accomplished using the Microsoft.Extensions.Logging.AzureAppServices provider This provider deposits additional log files into the blob container. For more information, see ASP.NET Core logging in Azure.

Failed request traces

Failed request traces are stored in XML files named fr######.xml. To make it easier to view the logged information, an XSL stylesheet named freb.xsl is provided in the same directory as the XML files. If you open one of the XML files in Internet Explorer, Internet Explorer uses the XSL stylesheet to provide a formatted display of the trace information, similar to the following example:

failed request viewed in the browser

Detailed error logs

Detailed error logs are HTML documents that provide more detailed information on HTTP errors that have occurred. Since they are simply HTML documents, they can be viewed using a web browser.

Web server logs

The web server logs are formatted using the W3C extended log file format. This information can be read using a text editor or parsed using utilities such as Log Parser.


The logs produced by Azure web apps do not support the s-computername, s-ip, or cs-version fields.

Next steps


If you want to get started with Azure App Service before signing up for an Azure account, go to Try App Service, where you can immediately create a short-lived starter web app in App Service. No credit cards required; no commitments.