Azure Troubleshooting

Azure Troubleshooting Skill

Structured diagnostic patterns for Azure resource health assessment and remediation. Provides KQL templates, metric baselines, severity classifications, and per-resource-type diagnostic workflows.

Quick Reference

Resource Discovery via Resource Graph

Find resources before diagnosing them:

// List all resources in a resource group with their health status
resources
| where resourceGroup == '{resourceGroupName}'
| project name, type, location, properties.provisioningState
| order by type asc, name asc

// Find resources with non-Succeeded provisioning state
resources
| where resourceGroup == '{resourceGroupName}'
| where properties.provisioningState != 'Succeeded'
| project name, type, properties.provisioningState

// Inventory resources by type
resources
| where resourceGroup == '{resourceGroupName}'
| summarize count() by type
| order by count_ desc

Diagnostic Settings Check

Verify every resource has diagnostic settings configured:

# List resources missing diagnostic settings
az monitor diagnostic-settings list \
  --resource "$resourceId" \
  --query "[].{name:name, workspace:workspaceId}" \
  --output table

If no diagnostic settings exist, create them using the pattern from the azure-bicep-patterns skill (Diagnostic Settings section).

Per-Resource Health Checks

App Service / Web Apps

// App Service error rate over last 24h
AzureMetrics
| where ResourceId contains '{appName}'
| where MetricName == 'Http5xx'
| where TimeGenerated > ago(24h)
| summarize Total5xx = sum(Total) by bin(TimeGenerated, 1h)
| order by TimeGenerated desc

Virtual Machines

// VM CPU spikes in last 6h
Perf
| where Computer == '{vmName}'
| where ObjectName == 'Processor' and CounterName == '% Processor Time'
| where TimeGenerated > ago(6h)
| summarize AvgCPU = avg(CounterValue), MaxCPU = max(CounterValue) by bin(TimeGenerated, 5m)
| where MaxCPU > 85
| order by TimeGenerated desc

Storage Accounts

SQL Database

Static Web Apps

Severity Classification

Classify every finding with consistent severity:

Diagnostic Workflow

Follow this six-phase sequence for any resource investigation:

Phase 1 — Discovery

# Get resource details
az resource show --ids "$resourceId" --query "{name:name, type:type, location:location, sku:sku, tags:tags}"

Phase 2 — Health Assessment

Run the resource-type-specific health checks from the tables above.

Phase 3 — Log Analysis

// Generic error search — last 24h
AzureDiagnostics
| where ResourceId contains '{resourceName}'
| where TimeGenerated > ago(24h)
| where Level == 'Error' or Level == 'Warning'
| summarize Count = count() by Level, OperationName
| order by Count desc

Phase 4 — Activity Log Review

# Recent operations that may have caused issues
az monitor activity-log list \
  --resource-id "$resourceId" \
  --start-time "$(date -d '24 hours ago' -u +%Y-%m-%dT%H:%M:%SZ)" \
  --query "[?status.value=='Failed'].{op:operationName.localizedValue, time:eventTimestamp, status:status.value, caller:caller}" \
  --output table

Phase 5 — Classification

Rate each finding using the severity table above. Include:

• Finding: What is wrong
• Severity: Critical / High / Medium / Low
• Evidence: KQL query result or CLI output
• Remediation: Specific fix steps

Phase 6 — Report Generation

Structure the diagnostic report as:

## Diagnostic Report: {resource-name}

**Assessment Date**: {date}
**Assessed By**: InfraOps Diagnose Agent
**Overall Health**: 🟢 Healthy | 🟡 Degraded | 🔴 Unhealthy

### Findings Summary

| # | Finding | Severity | Status |
|---|---------|----------|--------|
| 1 | ...     | High     | Open   |

### Detailed Findings

#### Finding 1: {title}
...

### Recommended Actions
1. ...

Common Remediation Playbooks

High CPU on App Service

1. Check if autoscale is configured — if not, add scale-out rule at 70% CPU
2. Review Application Insights for slow dependencies
3. Check for synchronous blocking calls in application code
4. Consider scaling up the App Service Plan SKU

Storage Account Throttling

1. Check current request rate against storage scalability targets
2. Enable CDN for read-heavy blob workloads
3. Distribute across multiple storage accounts if partition limits hit
4. Switch to Premium storage for high-IOPS requirements

SQL Database DTU Exhaustion

1. Identify top resource-consuming queries via Query Performance Insight
2. Add missing indexes suggested by Azure SQL advisor
3. Scale up DTU tier or switch to vCore for more granular control
4. Review connection pooling settings in application

Learn More

For issues not covered here, query official documentation: