Azure VM stuck at 'Creating' with no error message

You're in the Azure portal. You clicked Create on a new virtual machine — maybe a Standard_D2s_v3 running Windows Server 2022. The deployment starts, you see the spinner, and it just sits there. After 15 minutes, the status still says Creating. No error. No timeout. No notification. After 45 minutes, you refresh the page. Still Creating.

I've seen this exact thing happen dozens of times. The trigger is usually one of three things:

• You're deploying into a resource group that already has a lot of VMs or disks.
• You're hitting a regional vCPU quota limit that the portal doesn't warn you about.
• The VM is set to a disk performance tier that's not supported for your selected VM size.

Each can cause the provisioning engine to stall silently. No alert. No error in the activity log. The portal just hangs.

What's actually happening?

Azure's Resource Manager orchestrates the deployment. It checks quotas, allocates IP addresses, creates the OS disk, and configures the VM. If any step fails or times out — because of a quota limit or disk tier mismatch — the whole thing freezes. The Creating state is a catch-all. It doesn't mean the VM is halfway done. It means something upstream didn't respond, or never will.

The most common root cause I've seen: you have a regional quota of 10 vCPUs and you already have 8 vCPUs running in that region. Your new VM needs 4 vCPUs, which pushes you to 12. The portal shows deployment as successful in the UI, but the backend waits for quota to free up. It never does.

Second most common: your resource group is in a region that's running low on capacity for that specific VM series. Azure will hold your request in a queue instead of rejecting it outright. That's why you don't get an error.

Third: you chose a Standard SSD disk but selected a higher performance tier (like P20) that isn't supported by your VM size. The provisioning engine can't reconcile that, so it hangs.

The fix

Don't wait longer than 30 minutes. The VM isn't coming back. Cancel the deployment and start fresh.

1. Cancel the deployment. Go to the resource group, find the VM (it should be listed as Creating), click the three dots, and select Delete. This removes the stuck deployment and frees up any reserved IP addresses or disk names.
2. Check your quota. In the Azure portal, go to Subscriptions > Your Subscription > Usage + quotas. Set the location to the region you're deploying in. Look at the Total Regional vCPUs line. If your current usage plus the new VM's vCPUs exceed the limit, you need to request a quota increase. Click the pencil icon, enter a new limit (say 20 vCPUs), and submit. This takes 5 minutes or less for standard limits.
3. Pick a different VM size or region. If your quota is fine, the next step is to choose a different VM size. For example, if you tried a Standard_D2s_v3, switch to Standard_D2s_v4. These use different hardware clusters, and the capacity is often better. If that's not an option, deploy to a different region. I've had good luck with East US 2 and West Europe when US East was saturated.
4. Change the disk tier. When you configure your VM, the OS disk defaults to Premium SSD (if available) or Standard SSD. Don't change the disk SKU to a higher performance tier manually. For example, if you select Standard SSD, leave the tier at the default (P6 or P10). P20 or P30 tiers are only for Premium SSD disks and require a VM size that supports premium storage. If you're not sure, stick with the defaults.
5. Deploy again. Hit Create and wait. The deployment should complete in under 5 minutes. If it doesn't, cancel and repeat step 2–4 with a different combination.

What if it still fails?

If you've tried multiple VM sizes, regions, and disk tiers, and it still hangs, check these two things:

• Manage your resource group's lock status. Go to the resource group, click Locks. If there's a Read-Only lock, that blocks all resource creation. Delete the lock or change it to Delete only.
• Check for a policy that blocks creation. Go to Policy > Compliance. If there's a policy that restricts VM sizes or disk types, it can cause silent failures. You'll see non-compliant resources in the policy dashboard. Either adjust your deployment to comply or ask an admin to exempt the resource group from that policy.

Real talk: Azure's portal won't tell you any of this. The Activity Log for the deployment often shows Accepted and then nothing else. The real fix is to stop waiting, cancel, and check quota first. That's the step that solves 80% of stuck deployments.

If you're still stuck after all that, open a support ticket with Azure Support. Tell them you've already checked quota, changed VM sizes, and removed locks. They'll appreciate the head start, and you'll get a quicker resolution.