azure-diagnostics

Start by recording the resource ID, subscription, region, and UTC time window, then check Azure Service Health, Resource Health, and the activity log before interpreting application symptoms. Correlate logs, metrics, and recent configuration changes before attempting any remediation.

Inspect the active revisions, system and console logs, ingress target port, and probe type, port, path, and timing. A probe failure may come from an application crash, a port or path mismatch, or overly aggressive timing, so prove the cause before changing configuration.

Query AppExceptions for recent exceptions, AppRequests filtered by Success == false for failed requests, and AppDependencies for dependency failures, all bounded by a UTC time window. Verify table and column names against the workspace schema since they vary by telemetry mode.

A silent timeout commonly indicates an NSG deny, but it does not distinguish that from routing or firewall causes. Check DNS resolution from the source, evaluate source outbound and destination inbound NSG rules by priority, and inspect effective routes and private endpoint state.

Yes, the Skill provides safe read-only Azure CLI fallbacks such as az monitor activity-log list, az monitor metrics list, and az graph query, plus the portal's Diagnose and solve problems experience. Record that automated analysis was unavailable rather than inventing evidence.

Escalate only after documenting evidence that rules out narrower causes: service and resource health, configuration, identity, DNS, NSG rules, routes, private endpoints, firewalls, and application listeners. Present observed facts with sources and UTC time ranges alongside unavailable evidence.