How to Troubleshoot Azure Virtual Machine Scale Sets

Once you've reviewed the Activity Log, your next stop is Resource Health, specifically at the individual instance level. This is where Azure Virtual Machine Scale Sets troubleshooting gets granular.

In the Azure Portal, navigate to your scale set, then click Instances in the left menu. You'll see a list of all instances with their Provisioning state and Power state. Any instance showing Failed in the Provisioning state column is your target.

Click the failed instance name. In the instance detail view, go to Support + troubleshooting > Resource health. This gives you a health timeline specific to that VM, separate from the scale set's overall health. Look for events marked Degraded or Unavailable with timestamps matching when your problem started.

Now run this Azure CLI command to get the raw instance view, which includes extension-level failure detail that the portal sometimes hides:

az vmss get-instance-view \
  --resource-group "YourResourceGroup" \
  --name "YourScaleSetName" \
  --instance-id 0

Replace --instance-id 0 with the specific instance number. In the output, look for the extensions array. Each extension has a statuses field. A healthy extension shows "code": "ProvisioningState/succeeded". A broken one shows "code": "ProvisioningState/failed" with a message that tells you exactly which extension choked and why.

Common extension failures I see: Custom Script Extension timing out on a slow download, the Azure Monitor Agent failing because the workspace ID was wrong, or the Microsoft Dependency Agent crashing because the VM SKU doesn't have the right kernel version for the VM insights agent.

If you confirm an extension failure and the underlying VM is actually healthy, you can remediate without reprovisioning the whole instance by reapplying just the extension through the portal under Extensions + applications, or via:

az vmss update-instances \
  --resource-group "YourResourceGroup" \
  --name "YourScaleSetName" \
  --instance-ids 0

When it works, the instance provisioning state changes to Succeeded within 5–10 minutes and the instance moves into the load balancer's healthy pool.

One of the most insidious Azure Virtual Machine Scale Sets problems is when everything looks like it's working, instances provision successfully, the scale set shows a healthy status, but you're seeing constant scale-out and scale-in events. Instances spin up, get marked unhealthy almost immediately, and the scale set frantically tries to compensate. Your costs skyrocket and nothing actually handles traffic.

This is almost always a health probe misconfiguration. Here's how to diagnose it systematically.

First, check what health mode your VMSS is using. Navigate to your scale set > Health and repair in the left menu. You'll see either Application health extension or Load balancer health probe configured. Note which one.

If you're using a load balancer health probe, navigate to your Load Balancer resource, then Health probes. Check the probe settings carefully:

• Protocol: Is it HTTP or HTTPS? If your app only listens on HTTP but the probe is HTTPS, every probe silently fails.
• Port: Is the probe port actually open in your NSG (Network Security Group)? Azure's internal health probe traffic comes from the address 168.63.129.16, if your NSG blocks this, probes fail silently.
• Path: For HTTP probes, does the path return a 200 status code? Not a 302 redirect, not a 401, specifically 200. Many apps return 302 on the root path.

To verify NSG rules aren't blocking probe traffic, run:

az network nsg rule list \
  --resource-group "YourResourceGroup" \
  --nsg-name "YourNSGName" \
  --output table

Look for an inbound rule that allows TCP traffic from source AzureLoadBalancer service tag. If that rule is missing or has lower priority than a Deny rule, add it:

az network nsg rule create \
  --resource-group "YourResourceGroup" \
  --nsg-name "YourNSGName" \
  --name "AllowAzureLBHealthProbe" \
  --priority 100 \
  --source-address-prefixes AzureLoadBalancer \
  --destination-port-ranges 80 443 \
  --access Allow \
  --protocol Tcp \
  --direction Inbound

After fixing probe configuration, give it 5 minutes and check the Load Balancer's backend pool health under Backend pools > click your pool > view the health column. When it shows green checkmarks, your instances are genuinely healthy and the scale churn should stop.

Your autoscale rules look fine on paper. The CPU metric should be triggering a scale-out at 70%. But the VMSS just... sits there at two instances while your CPU screams at 90%. What's happening?

Azure autoscale has a dedicated diagnostic log that most people never look at. It's separate from the Activity Log and the Insights metrics. Go to your scale set > Scaling > then click the Run history tab in the autoscale blade. This shows every autoscale evaluation and exactly why it scaled, didn't scale, or got blocked.

Common reasons autoscale silently fails:

• Cooldown period active, After any scale event, autoscale won't fire again until the cooldown expires (default 5 minutes for scale-out). Check if your rules are triggering but getting blocked by an active cooldown.
• Min/Max capacity boundary, If your maximum instance count is set to 2 and you already have 2 instances, autoscale literally cannot scale out. Azure logs this as "already at maximum capacity" in the run history.
• Metric namespace not enabled, If you're scaling on a custom metric or a metric from Azure Monitor, the Diagnostic Settings for that metric must be enabled and flowing to the autoscale metric source. Check under your VMSS > Diagnostic settings.

To validate your autoscale configuration and simulate a scale event, use the Azure CLI autoscale settings command:

az monitor autoscale show \
  --resource-group "YourResourceGroup" \
  --name "YourScaleSetName-autoscale" \
  --output json

Check the profiles array. Each profile has rules, and each rule has metricTrigger and scaleAction. Verify that metricName exactly matches the metric name Azure exposes (spelling and case matter), and that metricResourceUri points to the correct resource ID.

If you want to force a test scale event without waiting for a metric threshold, you can manually override the instance count from the portal: Scaling > Manual scale > set a count > Save. This confirms the scale machinery itself works, and the issue is specifically with metric-triggered autoscale.

When autoscale starts firing correctly, you'll see green entries in the Run history tab with the reason "Scale out initiated" and the specific metric value that crossed the threshold.

This one catches experienced Azure engineers off guard. You updated your scale set's VM image, changed an environment variable, or modified the OS disk size. You saved the changes. But when you look at your instances, the Latest model column in the Instances view shows No for some or all of them. They're running the old configuration. How?

This is by design, and it's the Upgrade Policy biting you. Azure Virtual Machine Scale Sets support three upgrade modes:

• Manual, Instance models never update automatically. You must explicitly trigger an upgrade.
• Automatic, Azure updates instances automatically, restarting them in rolling batches.
• Rolling, Like Automatic, but with fine-grained control over batch size and health gates.

If you're on Manual mode and your instances show "No" in the Latest model column, you need to apply the model update. You can do this for all instances at once:

az vmss update-instances \
  --resource-group "YourResourceGroup" \
  --name "YourScaleSetName" \
  --instance-ids "*"

The * argument selects all instances. Warning: this causes rolling restarts. Do it during a maintenance window, or select specific instance IDs to stagger the updates.

If you're on Automatic or Rolling mode and updates still aren't applying, check the Health and repair configuration. Rolling upgrades pause when instances are unhealthy. If your health probe is returning failures (see Step 2), the rolling upgrade engine sees this as "upgrading broke the instance" and halts. Fix the health probe first, then the upgrade will resume automatically.

To check the current upgrade policy and spot potential conflicts:

az vmss show \
  --resource-group "YourResourceGroup" \
  --name "YourScaleSetName" \
  --query "upgradePolicy" \
  --output json

The output shows your current mode and, for Rolling mode, the rollingUpgradePolicy settings including maxBatchInstancePercent and maxUnhealthyInstancePercent. When instances successfully apply the new model, the Latest model column switches to Yes and provisioning state shows Succeeded.

Quota errors are the most fixable VMSS problem and the one people panic about the most. When your scale set tries to provision new instances and hits the regional vCPU limit, you get the error code OperationNotAllowed and Azure simply refuses to allocate any new VMs. Your autoscale rules keep trying, keep failing, and the instances stay at their current count while your workload suffers.

First, find out exactly which quota you've hit. In the portal: Subscriptions > select your subscription > Usage + quotas in the left menu. In the search box, type the VM family name you're using (e.g., Standard DSv3). You'll see your current usage vs. your limit.

If you're at or near 100%, you have two paths forward:

Path 1, Request a quota increase. Click the pencil icon next to the quota entry and submit a quota increase request. Azure typically approves these within minutes for common SKUs in well-utilized regions. For large increases (over 200 vCPUs) or less common SKUs, it might take a few hours and require business justification.

Path 2, Spread across regions or use a different SKU. If you need capacity immediately and can't wait for a quota increase, consider changing your VMSS to use a different VM SKU with available quota, or deploy a second scale set in a paired region.

For ongoing quota management, run this command to get a consolidated view of all compute quotas in a region:

az vm list-usage \
  --location "eastus" \
  --output table \
  --query "[?contains(name.localizedValue, 'Standard DSv3')]"

Replace eastus with your target region and the SKU filter with your VM family.

There's a second type of allocation failure that isn't quota-related: AllocationFailed with message "There are no more resources available for this subscription." This means Azure genuinely doesn't have physical capacity for that SKU in that region or availability zone right now. Solutions: use a different VM size, try a different availability zone in the same region (change the zones property on your scale set), or enable Spot instances as a fallback tier if your workload can tolerate preemption.

When quota is resolved and allocation succeeds, the Activity Log shows a new Create or Update Virtual Machine Scale Set operation with status Succeeded, and your instance count climbs to the requested level within a few minutes.