Azure Diagnostics

Build an evidence chain before changing a resource. Start with symptom, scope, time window, and recent changes; then select the narrowest diagnostic capability available in the active environment.

Diagnose systematically

1. Identify the affected resource ID, subscription, resource group, region, service, deployment revision, and UTC time window.
2. Check Azure service and resource health plus the activity log before interpreting application symptoms.
3. Use an AppLens-style automated diagnosis capability when the environment exposes one. Supply the exact resource scope and symptom, and retain the resulting observations rather than treating recommendations as proof.
4. Correlate logs, metrics, dependency signals, and recent configuration or deployment changes.
5. Route service-specific symptoms to the relevant playbook.
6. Record evidence, unavailable evidence, hypotheses, attempted remediation, and the result.

Do not invent evidence when a specialized integration is unavailable. Use a documented Azure CLI, portal, KQL, or Resource Graph fallback when it is safe and applicable.

Select a playbook