Diagnostic logs in App Service should be enabled

What does the recommendation "Diagnostic logs in App Service should be enabled" check?

Flags any App Service app, web app, function app or API app that has no diagnostic setting routing its platform logs to a destination. It looks for a diagnostic setting that ships categories such as AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs and AppServiceAuditLogs to a Log Analytics workspace, Storage account or Event Hub. It only checks that a sink exists and is enabled, not how long you retain the data or whether anyone queries it. It does not check whether your application code emits useful logs, and it does not cover the subscription-level Azure activity log, which records control-plane changes separately, nor the separate Application Insights instrumentation many teams add for traces.

Why does "Diagnostic logs in App Service should be enabled" matter?

Without diagnostic logs you cannot reconstruct who called the app, which requests failed, or what the runtime did during an incident. The default in-app filesystem logging is shallow and is wiped when the instance recycles or scales in, so by the time you investigate a suspected compromise the evidence is already gone. Shipping logs to a durable, queryable store means an authentication abuse pattern, a spike of 500s or a deployment that broke a payment flow leaves a trail you can search after the fact, instead of a blind spot that turns a contained issue into an unbounded one. It also underpins detection rules and compliance evidence: many frameworks expect you to prove that access to an internet-facing application was logged, and an empty workspace cannot satisfy an auditor or feed an alert.

How do I fix "Diagnostic logs in App Service should be enabled"?

1. Create a diagnostic setting on the app that forwards HTTP, console, application and audit logs to a Log Analytics workspace: 'az monitor diagnostic-settings create --name app-logs --resource <appResourceId> --workspace <workspaceId> --logs "[{category:AppServiceHTTPLogs,enabled:true},{category:AppServiceConsoleLogs,enabled:true},{category:AppServiceAppLogs,enabled:true},{category:AppServiceAuditLogs,enabled:true}]"'. Use a workspace, not a Storage account, if you want to query the data with KQL.
2. Turn on the underlying platform logging the categories depend on with 'az webapp log config --name <app> --resource-group <rg> --web-server-logging filesystem --detailed-error-messages true --failed-request-tracing true', which sets httpLoggingEnabled, detailedErrorLoggingEnabled and requestTracingEnabled. On Linux apps web-server logs are unavailable, so rely on application and console logs instead.
3. Bake the diagnostic setting into your Bicep or Terraform module as a 'Microsoft.Insights/diagnosticSettings' child resource of the site, so every new app inherits logging on deploy rather than waiting for someone to enable it by hand.

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"