Monitoring and Observability Diagnostics premium template-spec-upgraded field-manual-template-specs

Diagnostic setting

Diagnostic setting is an Azure Monitor configuration that sends platform logs and metrics from a resource to approved monitoring destinations. In Azure, it helps teams make resource telemetry available for troubleshooting, security investigation, compliance evidence, alerting, retention, and centralized analytics. Plainly, it is a named part of the architecture that operators can point to when they need evidence, ownership, and a safe change path. A useful glossary entry should explain where it appears, what it controls, what depends on it, and which signal proves it is healthy.

Back to glossary browser Open Microsoft Learn source
Aliases
Azure Monitor diagnostic setting, resource diagnostic setting, platform log routing, diagnostic settings
Difficulty
fundamentals
CLI mappings
4
Last verified
2026-05-13

Microsoft Learn

A diagnostic setting is an Azure Monitor configuration that routes platform logs and metrics from a resource to supported destinations such as Log Analytics, Event Hubs, or Storage.

Microsoft Learn: Diagnostic settings in Azure Monitor2026-05-13

Technical context

Technically, Diagnostic setting appears in Azure resource Monitoring blade, Azure Monitor diagnostic settings, resource IDs, log categories, metric categories, Log Analytics workspaces, Event Hubs, and Storage accounts and interacts with Azure Monitor, Log Analytics Workspace, Event Hubs, and Storage Account. Configuration is reviewed through log categories, metric categories, destination type, and retention plan, while operators validate live state through diagnostic setting list, selected categories, workspace destination, and event hub destination. Scope determines which permissions, logs, commands, and dependencies matter.

Why it matters

Diagnostic setting matters because a small Azure setting can shape customer experience, security posture, operational visibility, and incident recovery. When it is shallowly documented, teams may troubleshoot the wrong service, queue, device, policy, deployment, workspace, or destination while the real dependency remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit quality, clarifies ownership, and makes production changes safer because failure modes and graph relationships are visible before change. Treat Diagnostic setting as production owned when customer traffic, regulated data, device fleets, shared infrastructure, or release automation depends on it.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In Azure Portal blades and inventory exports where teams find Diagnostic setting with resource scope, state, owner tags, linked services, monitoring evidence, and recent change context.

Signal 02

In ARM, Bicep, Terraform, REST, or CLI output where teams review names, IDs, dependencies, permissions, routes, alerts, policies, deployment settings, and rollback evidence before approval.

Signal 03

In incident tickets, release reviews, and operational runbooks when engineers need proof that Diagnostic setting matches the expected production design and ownership model safely during support.

Signal 04

In automation pipelines where teams read, compare, export, or change Diagnostic setting settings with peer review, environment targeting, recorded command output, and production release approval.

Signal 05

In governance, cost, security, and reliability reviews where owners connect Diagnostic setting behavior to access, retention, monitoring, capacity, support responsibilities, shared platform teams, and decisions.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Route platform logs to Log Analytics for investigation.
  • Send diagnostic logs to Event Hubs for downstream security tooling.
  • Audit whether required resources have diagnostic settings enabled.
  • Prove that critical resources send logs and metrics to the right Log Analytics workspace, Event Hubs stream, or storage archive.
  • Fix blind spots where a resource exists but emits no platform evidence for audits, alerts, or incident investigations.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Diagnostic setting in action for financial services

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

WestBridge Finance, a financial services organization, needed to address an outage investigation had no platform logs for several production resources. The architecture team used Diagnostic setting as the control point for a measurable production improvement.

Business/Technical Objectives
  • Route critical logs to approved workspaces
  • Cut evidence collection time below one hour
  • Make missing diagnostics visible before incidents
Solution Using Diagnostic setting

The platform team created diagnostic settings for key production resources and sent logs to centralized Log Analytics workspaces. Event categories were mapped to incident runbooks, and Azure Policy checked new resources for missing telemetry. CLI output became the required evidence for support handoff. The team validated Diagnostic setting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Diagnostic setting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • Evidence collection time fell from six hours to forty minutes
  • New resources without diagnostics were flagged quickly
  • Incident reports included resource-level platform events
Key Takeaway for Glossary Readers

A diagnostic setting is often the difference between guessing and proving what happened.

Case study 02

Diagnostic setting in action for renewable energy operations

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CobaltGrid Energy, a renewable energy operations organization, needed to address security needed near-real-time resource logs for correlation with SIEM alerts. The architecture team used Diagnostic setting as the control point for a measurable production improvement.

Business/Technical Objectives
  • Stream selected logs to Event Hubs
  • Avoid exporting unnecessary noisy categories
  • Preserve local investigation queries in Log Analytics
Solution Using Diagnostic setting

Architects configured diagnostic settings with dual destinations for sensitive production resources. Security-relevant logs streamed to Event Hubs for SIEM processing, while operational logs went to Log Analytics. Category selections were reviewed quarterly to balance detection value and ingestion cost. The team validated Diagnostic setting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Diagnostic setting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • SIEM log delay stayed below five minutes
  • Noisy ingestion was reduced by 29 percent
  • Operations retained searchable logs for resource incidents
Key Takeaway for Glossary Readers

Diagnostic settings can serve security and operations when categories and destinations are chosen deliberately.

Case study 03

Diagnostic setting in action for healthcare SaaS

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

AtlasCare Scheduling, a healthcare SaaS organization, needed to address audit teams required proof that application infrastructure events were retained for regulated workloads. The architecture team used Diagnostic setting as the control point for a measurable production improvement.

Business/Technical Objectives
  • Retain platform logs in approved destinations
  • Document which categories are exported
  • Reduce manual evidence gathering for audits
Solution Using Diagnostic setting

The cloud governance team standardized diagnostic settings for production resource types. Workspaces had role-based access, storage retention met the audit requirement, and settings were captured in release evidence. Policy remediation created missing settings on supported resources after approval. The team validated Diagnostic setting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Diagnostic setting in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer.

Results & Business Impact
  • Audit evidence gathering dropped 64 percent
  • Unsupported or missing categories were documented
  • Access to retained logs followed least-privilege groups
Key Takeaway for Glossary Readers

Diagnostic settings turn observability requirements into concrete resource-level routing.

Why use Azure CLI for this?

CLI checks for Diagnostic setting are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, state, owner, permissions, destinations, deployment settings, or device records. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, access, or telemetry.

CLI use cases

  • Route platform logs to Log Analytics for investigation.
  • Send diagnostic logs to Event Hubs for downstream security tooling.
  • Audit whether required resources have diagnostic settings enabled.

Before you run CLI

  • Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact Azure scope.
  • Confirm resource group, service name, resource ID, environment, owner, and change record before collecting evidence or modifying production configuration.
  • Prefer read-only commands first; review any command that creates deployments, changes policy, alters device access, or routes telemetry before running it.

What output tells you

  • Whether the resource, setting, device, deployment, policy, queue, or API Management object exists at the expected Azure scope.
  • Which state, target, timestamp, SKU, identity, destination, count, property, or compliance result is visible to the operator.
  • Whether the issue is wrong scope, stale configuration, missing permissions, broken telemetry routing, policy drift, device provisioning failure, or release mismatch.

Mapped Azure CLI commands

Diagnostic setting operational checks

direct
az monitor diagnostic-settings list --resource <resource-id> --output table
az monitor diagnostic-settingsdiscoverMonitoring and Observability
read-only Microsoft docs
az monitor diagnostic-settings show --name <setting-name> --resource <resource-id>
az monitor diagnostic-settingsdiscoverMonitoring and Observability
read-only Microsoft docs
az monitor diagnostic-settings create --name <setting-name> --resource <resource-id> --workspace <workspace-id> --logs @logs.json --metrics @metrics.json
az monitor diagnostic-settingsprovisionMonitoring and Observability
mutating Microsoft docs
az monitor diagnostic-settings delete --name <setting-name> --resource <resource-id>
az monitor diagnostic-settingsremoveMonitoring and Observability
mutating Microsoft docs

Architecture context

Diagnostic setting belongs to Monitoring and Observability architecture decisions where identity, monitoring, cost ownership, reliability, and production support need shared evidence.

Security

Security for Diagnostic setting starts with least privilege, trusted configuration, and evidence that access matches workload risk. Review log destination access, sensitive log exposure, private endpoint path, least-privilege workspace access, and retention policy before approving production use. A common failure is assuming that a working feature, successful deployment, connected device, or populated log destination proves the configuration is safe. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, diagnostic logging, source-controlled definitions, and approval records where applicable. Keep exceptions ticketed, time-bounded, and owned. For regulated workloads, align the term with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale keys, unreviewed contributors, and undocumented exception paths before Diagnostic setting becomes an incident path.

Cost

Cost for Diagnostic setting appears through compute capacity, transaction volume, diagnostic retention, policy remediation, storage consumption, API exposure, message retries, device fleet operations, and the human effort required to recover from mistakes. Review Log Analytics ingestion, storage retention, event hub throughput, noisy categories, and query volume before expanding production use. Some costs are direct, such as retained logs, provisioned capacity, storage transactions, or queue processing; others are indirect, such as failed releases, duplicated troubleshooting, emergency restores, and support escalation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner and measurable value.

Reliability

Reliability for Diagnostic setting depends on repeatable configuration, tested dependencies, and clear failure signals. Watch required category coverage, destination availability, log ingestion health, policy remediation, and alert dependency because drift often appears later as failed releases, missing telemetry, stuck messages, failed device provisioning, unavailable APIs, or confusing support evidence. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and recovery notes before changing production. Operators should know which resource, endpoint, queue, policy, workspace, device, or downstream application fails first and which metric or log proves the failure. The goal is predictable recovery: detect Diagnostic setting drift, preserve service, restore safely, and explain the incident without guessing.

Performance

Performance for Diagnostic setting depends on workload shape, service limits, data volume, network path, diagnostic destination, policy evaluation, device scale, queue behavior, deployment capacity, and the monitoring path used to confirm success. Review ingestion latency, event hub throughput, workspace query speed, category volume, and destination throttling before increasing capacity or retrying blindly. The better fix might be correcting partitioning, reducing log noise, warming an endpoint, tuning queue visibility, selecting a different deployment type, or moving telemetry to a better destination. Measure under representative production conditions. Operators should connect symptoms to evidence: latency, throttling, backlog, failed operations, dropped logs, or stale state.

Operations

Operations for Diagnostic setting should focus on ownership, observability, and safe repeatability. Standardize names, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer the platform during incidents. Use read-only CLI, API, policy, diagnostic, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and recovery procedure before changing Diagnostic setting in a production environment.

Common mistakes

  • Changing production before checking the exact Azure scope, owner, identity, destination, and rollback or recovery procedure.
  • Treating a portal screenshot as sufficient evidence when CLI output, activity logs, diagnostics, and source-controlled configuration are repeatable.
  • Assuming a name match proves the correct resource when subscriptions, regions, products, device IDs, queues, and workspaces can look similar.