azure-troubleshooting

Azure Troubleshooting

A workspace skill for proceeding with Azure failure investigation, triage, initial confirmation, and recovery confirmation on a read-only basis, and distilling the results into a fact-based report.

When to Use

When you want to investigate failures, performance degradation, or reachability anomalies in Azure resources.
When you want to interpret Active / Updated / Resolved events in Azure Resource Health.
When you want to isolate the cause based on Load Balancer, VM, NIC, NSG, and Activity Log.
When you want to triage failures in AKS, App Service, Azure SQL, PostgreSQL, Cosmos DB, and Entra ID.
When you want to determine whether it is an Azure platform failure or a customer-side configuration / OS / application failure.
When you want to save the investigation results as a report for Troubleshooting/ .

When NOT to Use

When only performing normal product Q&A or comparative consideration.
When performing change work or recovery operations.
When the primary purpose is design proposals or organizing best practices.

Inputs

At minimum, receive one or more of the following.

Subscription ID
Resource ID or resource name + Resource Group
Occurrence time
Impact symptoms
Monitoring alert body

If anything is missing, confirm only the additional key information necessary for the investigation.

Core Rules

First check the live state on a read-only basis, and prioritize observed results over speculation.
Write the facts from Azure CLI / Activity Log / Resource Health separately from the interpretation based on them.
Activity Log is useful for checking control-plane history, but do not over-rely on it as proof of network runtime events.
First determine whether the failure is still ongoing or occurred in the past and has already been recovered.
Support the meanings attributed by Microsoft / Azure with official Docs.
Use Troubleshooting/ as the authoritative source for failure investigation reports, and do not store duplicates withAnswer/ .
For Load Balancer, even after Resource Health recovery, check VipAvailability / DipAvailability , and do not conclude VPN / BGP flap as 瞬断なし based only on Activity Log (for details, see service-branches.md）
In reports, avoid meta expressions like "as a report" and reduce them to the judgment statement itself.
Destructive operations, configuration changes, restarts, and failovers are outside the scope of this skill.

Workflow

Scope Fix: affected resource, time window, resource ID, and current user impact.
Live Fact Collection: auth/subscription, current resource state, Activity Log, Resource Health, and dependent resources.
Platform vs Workload Split: decide active Azure platform impact, recovered Azure event, or customer-side continuing issue.
Service Branch: use references/service-branches.md for shared network/DNS, Azure Firewall, ExpressRoute, AKS, App Service, Database, Entra ID, Load Balancer, VPN/BGP.
Official Grounding: verify Resource Health, diagnostic limits, and service-specific claims with Microsoft Learn URLs.
Report Synthesis: primary conclusion, facts, current state, interpretation, next checks, and SR identifiers if needed.
Save: troubleshooting records go to Troubleshooting/; ordinary Q&A answers go to Answer/.

Decision Points

Auth blocked: report MFA/Conditional Access status and prefer normal browser login when device code is blocked.
Resource Graph gaps: child resources may be missing; construct child IDs and query az resource show --ids directly.
Recovered Resource Health: do not call it ongoing once Resolved and current Available are confirmed.
Run Command RBAC: do not imply guest execution is possible without Microsoft.Compute/virtualMachines/runCommand/action or equivalent role evidence.
Incomplete scope: resolve resource ID / subscription / resource group first; do not broaden blindly.
No official doc: state that the official docs do not explicitly say it, and separate observation from hypothesis.

Done Criteria

Target resource and occurrence time are clear
Current state has been confirmed live
Activity Log or equivalent history has been confirmed
If network runtime is the issue, it has been determined whether Activity Log alone is sufficient or resource logs or metrics are necessary
It has been determined whether there is continued impact on the Azure side, recovery has occurred, or there is continued impact on the customer side
Attach at least one official Docs URL
Describe facts and interpretation separately
report Troubleshooting/ Save to , or clearly state the reason for determining the save destination

Output Shape

The report 回答、いただいた質問、事実確認結果、解釈、次に確認すべきこと as the basis. For the detailed template, use references/report-template.md .

Support Response Translation

If you hand technical answers from support or other vendors directly to the customer, the document becomes nothing more than suspected points lined up in parallel, and the customer cannot decide where to start. Rewrite it into the following form before handing it over.

For each item, first determine 'on which host, and by whom' it will be carried out. This is often not written in the answer body, and if this is missing, work begins with the misunderstanding left unaddressed.
Items already assessed in the answer as 'unlikely' are explicitly downgraded. If they remain listed in parallel, it looks like all items are being investigated, and the customer's workload swells beyond the actual scope.
Separate 'what can be done now' from 'what to collect when the issue is reproduced.' For intermittent events, if preparations for collection at reproduction time are not completed first, the evidence itself cannot be obtained.
Attach a mapping table between the sections of the original answer and the work items, so the customer can read it side by side with the original text.
Show multi-stage dependencies (CNAME chains, routes, dependent services) with diagrams rather than prose, so it is clear at a glance at which stage the failure is occurring.
Do not mix in speculation that is not in the original answer. Write our interpretation in a way that distinguishes it as interpretation.

Example Prompts

/azure-troubleshooting subscription ID と resource ID を渡すので、Azure 側継続障害か切り分けて
/azure-troubleshooting Resource Health の PlatformInitiated アラートが来た。current state と Activity Log を見て報告書を作って
/azure-troubleshooting Load Balancer と配下 VM の障害調査をして、Troubleshooting に保存して
/azure-troubleshooting AKS の API server は生きていそうだが Pod が不安定。Azure 側かワークロード側か切り分けて
/azure-troubleshooting App Service が 5xx を返している。platform 障害か app 側か切り分けて
/azure-troubleshooting Azure SQL / PostgreSQL の接続障害を調べて、platform とネットワークを切り分けて
/azure-troubleshooting Entra ID のサインイン障害を tenant-wide か app-specific か切り分けて

About this skill