Azure VM Sizing and Boot Time: When a Reboot Takes 30 Minutes

You reboot an Azure VM and wait. And wait. Twenty minutes go by. Thirty. No crash alert, no error in the portal, no obvious reason. The VM eventually comes back but the delay is unexplained and it keeps happening.

Before you open a support ticket or rebuild the image, check the VM size.

// what's actually happening

Azure VM boot time is directly tied to the underlying hardware allocation process. When a VM is deallocated and restarted — or rebooted through the OS — Azure has to allocate physical hardware resources for that VM's size tier in the target availability zone.

For smaller, common VM sizes (Standard_B2s, Standard_D2s_v3), hardware is abundantly available and allocation is near-instant. For larger or less common sizes — especially memory-optimized, compute-optimized, or older generation SKUs — Azure may need to find available hardware in the region, which can take significantly longer.

The symptom is a long boot time with no error. The portal shows the VM as "Starting" for an extended period. This is not a guest OS issue. The VM hasn't even started booting yet.

// how to confirm this is the cause

Check the VM's activity log in the Azure portal during the next reboot:

1. Go to the VM → Activity log
2. Filter for the reboot event
3. Look at the time between "Microsoft.Compute/virtualMachines/start/action" initiated and completed

If the gap is 15+ minutes at the Azure operation level (before the guest OS even starts), the issue is allocation time, not OS boot time.

You can also check from the CLI:

az vm get-instance-view \
  --resource-group <rg-name> \
  --name <vm-name> \
  --query "instanceView.statuses"

Watch the ProvisioningState and PowerState transitions during a reboot.

// the fix

Option 1 — Change to a more available VM size

Resize to a SKU in the same family that has better regional availability. Standard_D series v4 and v5 generally have faster allocation times than v2 or v3 in most regions.

az vm resize \
  --resource-group <rg-name> \
  --name <vm-name> \
  --size Standard_D4s_v5

Option 2 — Reserve the instance

Azure Reserved Instances pre-allocate capacity for your VM size. If you're running this VM long-term, a 1-year reservation eliminates the allocation wait entirely and reduces cost.

Option 3 — Use Scheduled Events to prepare for reboots

If the VM runs workloads that can't tolerate unexpected 30-minute windows, implement Azure Scheduled Events. The VM gets advance notice of platform maintenance reboots and can gracefully drain connections before the reboot occurs.

// the takeaway

Long Azure VM boot times with no error are almost always a capacity allocation issue tied to VM size, not a guest OS or image problem. Check the activity log first, resize to a more available SKU if needed, and consider reservations for production workloads where boot time matters.