How to Check Azure App Service Logs

Teams learn how to check Azure App Service logs only after an outage, when pressure is highest, and data is already gone.

Azure App Service is a managed platform for hosting web apps and APIs. It gives you several log types, and each one lives in a different place. You will learn what each log captures and how to turn it on. You will also learn how to stream, download, and query logs, and how to keep them secure and affordable.

Understand the Types of Azure App Service Logs

Before you click anything, know what each log type records. Turning everything on without a plan fills storage and hides the useful lines.

Two terms need a quick definition. A status code is the number a web server returns, such as 200 for success or 500 for a server error. Log level is the severity filter, such as Error, Warning, Information, or Verbose.

Here is the part many people miss. Application logging only shows what your developers chose to write. If the code never logs anything, the log is empty. I always ask developers to log at startup, around external calls, and in every exception handler.

Pro Tip: In my experience, the first ten minutes of an incident are wasted when nobody knows which log type holds the answer. I keep this table in our runbook so on-call engineers pick the right source immediately.

Plan Your Logging Before You Enable It

Start with the business requirement. A short-lived troubleshooting session needs different settings than a regulated production app that must retain logs for 90 days.

Choose a Log Destination

App Service can send logs to three kinds of places:

• File system: Stored on the app’s own storage. It is quick for live debugging, but small and temporary.
• Blob storage: Stored in an Azure Storage account. It is cheap and durable, but harder to search.
• Azure Monitor with Log Analytics: Sent through diagnostic settings to a workspace you query with KQL. This is best for production. For background, read what Azure Monitor does.

The file system option has limits that surprise people. App Service caps file system logs at a small size, and the setting turns itself off after about 12 hours to protect the app. That makes it a debugging tool only, not a retention plan.

Match the Plan Tier to Your Needs

Logging uses the same compute as your app. On a small shared plan, verbose logging can slow requests. Learn how plans work in this Azure web app service plan guide. In development, I use verbose logs freely. In production, I stay at Information or Warning and raise the level only for short windows.

Create the Resource Group and Workspace First

Keep logging resources in their own resource group, a logical container for related resources. This protects your logs if someone deletes the app group.

az group create \
  --name rg-monitoring-prod \
  --location eastus

az monitor log-analytics workspace create \
  --resource-group rg-monitoring-prod \
  --workspace-name log-appsvc-prod-eastus \
  --location eastus \
  --retention-time 60

The first command creates rg-monitoring-prod in the East US region, a geographic location where Azure services run. The second creates a Log Analytics workspace in it. The --retention-time 60 parameter keeps data for 60 days, so set it to match your compliance needs. Longer retention costs more.

Pro Tip: I place the workspace in the same region as the app. Cross-region log shipping can add latency and data residency questions I would rather not explain to an auditor.

Check Azure App Service Logs in the Azure Portal

The portal is the fastest path for a first look. It suits a developer or admin who needs answers right now.

Step 1: Turn On App Service Logs

1. Open your App Service in the Azure portal.
2. Under Monitoring, select App Service logs.
3. Set Application logging to File System (temporary) or Blob.
4. Choose a Level. Start with Information.
5. Turn on Web server logging and set it to File System.
6. Turn on Detailed error messages and Failed request tracing if you are on Windows.
7. Select Save.

Saving may restart the app on some configurations. This can cause a brief interruption, so do it in a quiet window for production apps.

Step 2: Watch Live With Log Stream

Open Log stream under Monitoring. You will see output as requests arrive. Open your site in another tab and click around. Your messages should appear within seconds.

This is the quickest way to catch a startup crash. It is also where I found that logistics company’s missing setting. The app threw a clear exception on the first request.

Step 3: Use Diagnose and Solve Problems

The Diagnose and solve problems blade runs built-in detectors. It checks for things like high CPU, memory pressure, and HTTP 5xx spikes. Beginners often skip it, but it saves time. It gives a plain-language summary and points at likely causes.

If your errors are 500s, my guide to the Azure App Service 500 internal server error walks through common fixes. If users see a stopped-site message, check error 403 this web app is stopped.

Pro Tip: I open Diagnose and solve problems before I read a single log line. About half the time, the detector names the exact problem and saves me an hour of digging.

Check Azure App Service Logs With Azure CLI

Scripting matters once you manage more than one app. It also helps you repeat the same steps in a pipeline. If you need setup help, see what Azure CLI is and the Azure CLI login guide.

Enable Logging

az webapp log config \
  --name <app-name> \
  --resource-group <resource-group-name> \
  --application-logging filesystem \
  --level information \
  --web-server-logging filesystem \
  --detailed-error-messages true \
  --failed-request-tracing true

This command configures logging on one web app.

• --application-logging filesystem stores app messages on the app’s file system.
• --level information filters out Verbose and Debug noise.
• --web-server-logging filesystem records HTTP request data.
• --detailed-error-messages and --failed-request-tracing capture deeper error detail on supported Windows apps.

Stream Logs to Your Terminal

az webapp log tail \
  --name <app-name> \
  --resource-group <resource-group-name>

This streams log output live in your terminal, like the portal’s Log stream. Press Ctrl+C to stop. It is perfect for watching a deployment finish or reproducing a bug on demand.

Download a Log Archive

az webapp log download \
  --name <app-name> \
  --resource-group <resource-group-name> \
  --log-file appservice-logs.zip

This downloads a ZIP file containing the stored logs. The --log-file parameter sets the local file name. This writes data to your machine, so avoid shared or unmanaged computers. Logs can hold usernames, IP addresses, and sometimes tokens that were logged by mistake.

Check Your Current Logging Settings

az webapp log show \
  --name <app-name> \
  --resource-group <resource-group-name>

This shows what logging is enabled right now. I run it first on any inherited app, because I never trust that someone else turned logging on.

If you are new to Azure scripting, the Azure CLI examples for beginners article is a good warm-up. Cloud Shell works well here too, and what Azure Cloud Shell is explains how to open it without installing anything.

Pro Tip: I once left file system logging at Verbose after a late-night fix. The app slowed down the next day. Now I add a calendar reminder to lower the level after every incident.

Check Azure App Service Logs With Azure PowerShell

Windows-focused teams often prefer PowerShell. The same steps apply, but the cmdlets differ. First review the Azure PowerShell tutorial if you have not used the Az module.

Confirm the App and Its Settings

$SubscriptionId    = "<subscription-id>"
$ResourceGroupName = "<resource-group-name>"
$AppName           = "<app-name>"

Set-AzContext -SubscriptionId $SubscriptionId
Get-AzWebApp -ResourceGroupName $ResourceGroupName -Name $AppName |
  Select-Object Name, State, HttpLoggingEnabled, DetailedErrorLoggingEnabled

Set-AzContext points your session at the right subscription, the billing and governance boundary for resources. Get-AzWebApp reads the app, and Select-Object shows its state and logging flags. See the Get-AzWebApp reference for more properties.

Send Logs to Log Analytics

$AppResourceId = (Get-AzWebApp -Res