Azure Diagnostic Settings Policy: Logs Before Incidents

An Azure diagnostic settings policy is the kind of guardrail that feels boring right up until the outage bridge starts and nobody can find the logs. Resource logs aren’t collected by default for every Azure resource, so turning on diagnostics after the incident is like buying a smoke alarm after the fire.

The better pattern: use Azure Policy to deploy diagnostic settings automatically, send the right resource logs to a Log Analytics workspace, and remediate existing resources before the next mystery 403, throttling event or failed backend call.

Why an Azure diagnostic settings policy belongs in your baseline

Azure Monitor diagnostic settings route platform logs, metrics and activity log data to Log Analytics, Event Hubs and Storage. The catch is that they’re configured per resource, and resource logs aren’t collected by default. That’s fine in a lab and painful in production.

The real win is consistency. Instead of asking every project team to repeat the same portal clicks, assign built-in Azure Policy initiatives where they exist, write custom policies where they don’t, and use remediation tasks to bring older resources into compliance.

What to send: audit vs. allLogs

Microsoft recommends category groups because they adjust as log categories evolve. The two you’ll see most often are audit and allLogs.

A practical default: start with audit broadly, use allLogs selectively for tier-0 and tier-1 workloads, and watch cost, since Log Analytics charges are driven mainly by ingestion and retention.

Recommended rollout pattern

Don’t assign one giant “log everything everywhere forever” policy and then act surprised when Finance calls. Roll it out deliberately.

1. Pick the destination architecture first

For most admin teams the default destination is a Log Analytics workspace: KQL, alerts, workbooks and one place to troubleshoot. Event Hubs fits SIEM and streaming scenarios; Storage fits long-term archive. Many organizations use more than one, but start with the reason before enabling the pipe.

2. Separate production and sandbox logging

Production needs reliable retention, alerting and access control. Sandboxes need guardrails too, but rarely the same volume. Use management groups, subscriptions or assignment parameters so every experiment isn’t treated like the crown jewels.

3. Prefer built-in policies, then fill gaps

Microsoft provides built-in initiatives for many resource types, and they’re easier to support over time. For resources without one, Microsoft documents a custom policy approach and points to tooling such as Create-AzDiagPolicy for generating policy files.

4. Assign with a managed identity and remediate

Policies using deployIfNotExists need a managed identity for remediation. New and updated resources are evaluated automatically, but existing non-compliant resources need a remediation task. Assigning the policy is step one; clearing the backlog is step two.

Azure CLI example: assign a built-in initiative

The exact initiative depends on your destination and category group. This shows the shape of the rollout; review the definition in your tenant before using it.

# 1) Find diagnostic settings initiatives
az policy set-definition list \
  --query "[?contains(displayName, 'Diagnostic settings')].[displayName, name]" \
  -o table

# 2) Assign the selected initiative at a management group, subscription or resource group scope
az policy assignment create \
  --name deploy-diagnostic-settings-log-analytics \
  --display-name "Deploy diagnostic settings to Log Analytics" \
  --policy-set-definition <initiativeDefinitionId> \
  --scope <scopeId> \
  --params '{"logAnalytics":{"value":"<workspaceResourceId>"}}' \
  --assign-identity \
  --location eastus

After assignment, create a remediation task for existing resources from the policy compliance view in the portal, or with the CLI remediation commands.

Troubleshooting when the policy doesn’t deploy

• Identity: confirm the assignment’s managed identity exists and has the required roles.
• Scope: verify the assignment scope actually includes the resource.
• Resource type: confirm it supports diagnostic settings and the selected categories.
• Destination: check that the workspace, Event Hub or Storage account exists and is reachable.
• Timing: deployIfNotExists evaluation and remediation aren’t instant.

Pair policy compliance with service-specific logs. App Service and Key Vault issues, for example, get much easier to explain once platform logs exist; see App Service Key Vault reference fixes. For drift detection, pair this guardrail with Azure Resource Graph guardrail queries.

KQL starter checks after logs arrive

Validate the pipeline before you trust it. Tables vary by provider and destination mode, but these checks confirm recent ingestion and find noisy resources:

// Recent AzureDiagnostics volume by resource type
AzureDiagnostics
| where TimeGenerated > ago(24h)
| summarize Events=count() by ResourceProvider, ResourceType
| order by Events desc

// Top talkers by resource
AzureDiagnostics
| where TimeGenerated > ago(24h)
| summarize Events=count() by Resource, ResourceGroup, SubscriptionId
| top 20 by Events

Use the results to tune categories, alert rules and retention. If ingestion grows faster than expected, see Log Analytics cost guardrails.

Azure diagnostic settings policy governance checklist

• Define which resource types require audit, allLogs or custom categories.
• Document approved Log Analytics workspaces and destination rules.
• Separate production from sandbox policies by management group or subscription.
• Give the policy managed identity least-privilege roles.
• Run remediation tasks for existing resources and track compliance drift.
• Review ingestion cost, retention and noisy tables monthly.
• Connect critical signals to alerts, workbooks and runbooks, including Azure Service Health alerts.

Last reviewed: October 2026

Sources

• Diagnostic settings in Azure Monitor (Microsoft Learn)
• Enable diagnostic settings by category group using built-in policies (Microsoft Learn)
• Create diagnostic settings at scale using Azure Policy (Microsoft Learn)
• Azure Policy deployIfNotExists effect (Microsoft Learn)
• Resource logs in Azure Monitor (Microsoft Learn)
• Azure Monitor Logs cost calculations and options (Microsoft Learn)