A Windows VM running an internal line-of-business app stops responding after Monday’s patching. Users see timeouts, the help desk is flooded, and someone on the team suggests “just rebooting it.” That is usually the right move, but I have also seen a rushed reboot take down a database mid-transaction and a pipeline run that targeted the wrong VM.
Knowing how to restart a VM in Azure safely means knowing more than where the button is. You need the right permissions, the right tool for the job, and a plan for what happens to your disks, IP addresses, and dependent services. A restart is a graceful operating system reboot on the same host, and it is the lowest-risk fix for many hangs.
This guide covers the Azure portal, Azure CLI, and Azure PowerShell methods, plus permissions, automation, verification, and what to do when a restart does not fix the problem.
Restart vs. Stop vs. Redeploy
Azure gives you several power actions, and they behave differently. Picking the wrong one causes surprises.
| Action | What happens | Typical use |
|---|---|---|
| Restart | Reboots the guest OS; the VM stays on the same host and stays allocated | Hung services, post-patch reboots |
| Stop (deallocate) | Shuts down and releases compute resources | Saving compute cost |
| Redeploy | Moves the VM to a new host and powers it on; the temporary disk is lost | Host-level or connectivity problems |
| Reapply | Re-runs the VM’s provisioning configuration without a host move | VMs stuck in a failed state |
A restart keeps the VM allocated, so its network interface, private IP, OS disk, data disks, and temporary disk contents stay in place. A deallocate releases the compute, and a dynamic public IP address can change when the VM comes back. For a deeper comparison, read Azure VM restart vs. stop and what “stopped (deallocated)” means.
Billing matters too. A restart does not change compute billing, because the VM never stopped being allocated. If you shut a VM down from inside the operating system, it can show as “Stopped” but remain allocated and billed. See whether Azure charges for a stopped VM.
Pro Tip: In my experience, most “reboot” tickets I have handled needed a plain restart, not a redeploy. I try the cheapest, least disruptive action first and only escalate when the VM stays unhealthy.
Check Permissions Before You Restart
Azure RBAC (role-based access control) assigns permissions through roles instead of broad administrator access. To restart a VM, an identity needs the Microsoft.Compute/virtualMachines/restart/action permission. The built-in Virtual Machine Contributor role includes it, and so do Contributor and Owner at a higher scope.
Give the least access that gets the job done. A help desk engineer who only reboots servers should not be an Owner on the subscription. Scope the role to one Azure resource group or a single VM, or create a custom role that allows only restart, start, and read actions.
For background, see what RBAC is, Owner vs. Contributor, and how to give access to a resource group. To see your own permissions, use how to check your permissions in the Azure portal.
If the Restart button is grayed out or a command fails with an authorization error, a missing role assignment is the first thing to check. Test the role with a non-administrator account before you rely on it during an incident.
Pro Tip: I recommend assigning the restart role to a group in Microsoft Entra ID, not to individuals. When people change teams, you update group membership instead of hunting for stray role assignments.
How to Restart a VM in Azure Using the Portal
The portal is the fastest option for a single VM. The Azure portal is Microsoft’s web interface for managing resources.
- Sign in to the Azure portal. If you need help, see how to sign in to the Azure portal.
- Search for Virtual machines and select the VM you want.
- Confirm the name, resource group, and subscription at the top of the page. Wrong-VM mistakes happen here.
- Select Restart