How to Troubleshoot Azure

This is always Step 1. I don't care how confident you are that the issue is on your end, check this first. Azure Service Health gives you real-time visibility into platform incidents, planned maintenance windows, and health advisories affecting your specific subscriptions and regions.

In the Azure portal, search for Service Health in the top search bar and open it. You'll see four tabs: Service Issues, Health Advisories, Security Advisories, and Planned Maintenance. Click Service Issues first. Use the filters at the top to narrow by your subscription, the affected region (East US, West Europe, etc.), and the service type (Virtual Machines, Storage, Azure SQL, etc.).

If you see an active incident, click it to read the impact statement and estimated resolution time. Microsoft posts updates there every 30–60 minutes during active incidents. You can also configure alerts so you get an email or webhook notification the moment an incident is declared. Do this now, don't wait until the next outage:

az monitor activity-log alert create \
  --name "AzureServiceHealthAlert" \
  --resource-group YourResourceGroup \
  --condition category=ServiceHealth \
  --action-group /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Insights/actionGroups/{ag-name}

Next, check the Activity Log. Navigate to your resource group or subscription, click Activity log in the left menu, and filter the timeframe to "Last 1 hour" or "Last 6 hours" depending on when the issue started. Look for entries marked with a red circle, those are failed operations. Click any failed entry to expand it and see the full JSON response, which almost always contains the actual error code buried in the statusMessage field. That's the real error. Whatever the portal surface showed you was just a summary.

What you should see if it's working: Either a green "Available" status in Service Health with no active incidents, or a clear error code in the Activity Log that you can now look up specifically.

A disabled, over-quota, or spending-limited subscription is one of the most common reasons Azure resources fail to deploy or start, and one of the most confusing, because the error messages don't always say "subscription problem" directly. You might see QuotaExceeded, SubscriptionNotFound, BillingAccountNotFound, or just generic deployment failures.

Go to Subscriptions in the portal. Check the Status column. If it says anything other than "Active", here's what to do:

• Disabled (spending limit reached): Click the subscription, then click Spending limit at the top. Click Remove spending limit. You'll need a credit card on file. This only applies to free trial and MSDN/Visual Studio subscriptions, pay-as-you-go subscriptions don't have spending limits.
• Disabled (payment failed): Go to Cost Management + Billing, click Payment methods, and update your card. It can take up to 24 hours for the subscription to re-enable after payment is processed.
• Disabled (policy): This usually happens in enterprise agreements. Contact your Azure billing admin or open a support ticket with Microsoft.

For quota errors, run this command to see your current vCPU usage and limits in a region:

az vm list-usage --location "eastus" --output table

If you're hitting quota, you can request an increase directly in the portal. Go to Help + Support, click New support request, select Service and subscription limits (quotas) as the issue type, choose your subscription, then select Compute-VM (cores-vCPUs) subscription limit increases. Standard increases are usually approved within a few hours. Larger increases (say, 500+ cores) may require a business justification and can take 1–3 business days.

What success looks like: Subscription status shows "Active" and your deployment retries succeed without a quota-related error code.

Authentication failures are the second most common Azure troubleshooting scenario I deal with. The error codes are frustratingly cryptic, AADSTS50076, AADSTS70011, AADSTS65001, AuthorizationFailed, and the fix depends entirely on which one you have. Let me break down the most frequent ones.

AADSTS50076, MFA required: Your account requires multi-factor authentication but the token request didn't include it. This often happens with service principals or automation scripts. If this is interactive login, just complete the MFA prompt. If it's a service principal, you need to check your Conditional Access policies in Entra ID, a policy may have been applied that now requires MFA for service principal logins in certain contexts.

AADSTS70011, Invalid scope: The application is requesting a permission scope that doesn't exist or isn't consented to. Check your app registration in Entra ID under App registrations → [Your App] → API permissions. Verify the requested scopes exist and click Grant admin consent if needed.

AuthorizationFailed, RBAC issue: Your account doesn't have the right role on the resource. Run this to see your current role assignments:

az role assignment list --assignee your@email.com --output table

If you need to assign a role (and you have Owner or User Access Administrator on the scope), run:

az role assignment create \
  --assignee your@email.com \
  --role "Contributor" \
  --scope /subscriptions/{subscription-id}/resourceGroups/{resource-group-name}

Token cache corruption: If your Azure CLI commands started failing suddenly after a long session, clear the token cache entirely:

az account clear
rm -rf ~/.azure/msal_token_cache.json
az login

On Windows, the token cache lives at C:\Users\{username}\.azure\msal_token_cache.json, delete that file and re-authenticate.

What success looks like: az account show returns your subscription details without error, and you can list resources with az resource list --output table successfully.

Deployment failures are where Azure troubleshooting gets genuinely technical. You've clicked Deploy (or run your Bicep/ARM template), and you get back "The resource operation completed with terminal provisioning state 'Failed'." Here's how to actually find out what went wrong.

In the portal, go to your Resource Group and click Deployments in the left menu. You'll see a list of all deployments, click the failed one. On the overview page, you'll see which specific resources failed. Click the failed resource name, then click Operation details. This is where the real error lives, nested in the response body JSON.

From the CLI, you can get deployment operation details with:

az deployment group show \
  --resource-group YourResourceGroup \
  --name YourDeploymentName \
  --query properties.error

Common deployment error codes and their fixes:

• InvalidTemplateDeployment / RequestDisallowedByPolicy: An Azure Policy is blocking the deployment. Run az policy assignment list --scope /subscriptions/{sub-id} --output table to see active policies. Contact your Azure admin if you need an exemption.
• SkuNotAvailable: The VM size or SKU you requested isn't available in that region. Run az vm list-skus --location eastus --size Standard_D --output table to find available SKUs. Consider switching to a different region or a comparable SKU.
• ResourceQuotaExceeded: You've hit a per-resource-type quota. See Step 2 for quota increase instructions.
• ParentResourceNotFound: You're trying to deploy a child resource before the parent exists. Check your template's dependsOn declarations.

For Bicep-specific issues, run a what-if analysis before deploying to catch problems ahead of time:

az deployment group what-if \
  --resource-group YourResourceGroup \
  --template-file main.bicep \
  --parameters @parameters.json

What success looks like: The deployment shows "Succeeded" in green on the Deployments blade, and all expected resources appear in the resource group.

Networking problems are the sneakiest Azure troubleshooting category. Everything looks right, the resource is running, your credentials are valid, there's no service incident, but you still can't connect. Nine times out of ten, the culprit is an NSG rule, a missing route, or a DNS resolution failure inside a Virtual Network.

Start with Network Watcher. In the portal, search for Network Watcher and open it. The two tools you'll use most are IP flow verify and Connection troubleshoot.

IP flow verify tells you if a specific traffic flow (source IP, destination IP, port, protocol) is allowed or denied by your NSG rules, and which exact rule is responsible:

az network watcher test-ip-flow \
  --direction Inbound \
  --local 10.0.0.4:3389 \
  --protocol TCP \
  --remote 203.0.113.10:*  \
  --vm MyVM \
  --resource-group MyRG \
  --nic MyNIC

Connection troubleshoot checks end-to-end connectivity from a VM to a target, including latency and hop analysis:

az network watcher test-connectivity \
  --source-resource MyVM \
  --dest-address 8.8.8.8 \
  --dest-port 443 \
  --resource-group MyRG

NSG rule audit: View all rules on an NSG sorted by priority:

az network nsg rule list \
  --nsg-name MyNSG \
  --resource-group MyRG \
  --output table

Remember: NSG rules are evaluated in priority order (lowest number first). A Deny rule at priority 100 beats an Allow rule at priority 200. If your traffic is being blocked, look for high-priority deny rules covering your port range.

DNS issues inside VNets: If your VMs can't resolve internal names, check your Virtual Network's DNS server configuration. Go to Virtual Networks → [Your VNet] → DNS servers. If you're using Azure-provided DNS (168.63.129.16), make sure your NSG isn't blocking UDP port 53 to that address, that's a mistake I've seen more times than I can count.

What success looks like: IP flow verify returns "Allow" for your expected traffic flows, and connection troubleshoot shows "Reachable" for your target endpoints.