Most people troubleshooting an Azure Virtual Machine (VM) for the first time panic because the error messages don't match anything they've seen before. A VM that was running fine yesterday is suddenly unreachable. The Azure portal shows one status, but the actual machine behaves differently. Without a structured approach, you'll click randomly through settings, change things that make it worse, and waste two hours when the fix was thirty seconds away.
This guide walks you through exactly where to start, what to check first, and when you actually need to escalate rather than spend more time digging.
This is the most common reason VMs appear to be "down" but aren't actually broken.
In Azure Portal, open your Virtual Machine and look at the Status line. You're looking for two separate indicators:
What's the difference? A deallocated VM has been shut down but the disk still exists and you're not paying for compute (though you're still paying for storage). A running VM is active and ready. If your status shows "VM deallocated", the machine isn't responsive because it literally isn't running.
How to fix it: Click "Start" at the top of the VM's overview page. Wait 60 to 90 seconds. The status will change to "VM running" and the allocation state will show "allocated".
This solves roughly 30% of beginner VM issues. Seriously.
If the VM is running and allocated but you still can't connect (via RDP on Windows, SSH on Linux), your firewall rules are blocking you.
Network Security Groups act like a firewall. They sit between you and the VM and only allow traffic matching specific rules.
What to check:
Common mistake: A default NSG allows nothing. You need to explicitly add a rule. Port 22 or 3389 won't be open by default, even though the VM itself is fine.
How to fix it: Click "Add inbound security rule" and create one that allows:
Wait a minute for the rule to activate. Try reconnecting.
Some VMs are internal only and can only be accessed from within the Azure network. Others are meant to be publicly accessible. If you're trying to connect from outside Azure (from your laptop at home, for example), the VM needs a public IP.
How to check:
How to fix it:
Even if network traffic reaches the VM, Windows Defender Firewall or Linux iptables might be blocking it.
If you can get to the VM at all (or if you're troubleshooting a connectivity issue to an internal service), check the operating system's own firewall.
Windows: Open Windows Defender Firewall and confirm that RDP (port 3389) is allowed in the inbound rules.
Linux: Run `sudo iptables -L` to list rules, or check `sudo ufw status` if UFW is enabled.
The fix varies by OS, but the principle is the same: the application or port you're trying to reach needs to be explicitly allowed.
A VM might be technically "running" but completely unresponsive because it's out of resources (CPU, memory, or disk space).
How to check:
What to do:
If the VM is running but completely unresponsive to SSH or RDP, the serial console can show you what's actually happening at boot.
How to access it:
This is especially useful when the VM is stuck in a restart loop or won't boot at all. The serial console shows you exactly where it's failing.
Azure can automatically capture logs and screenshots of what the VM is doing.
How to enable it:
What you'll see:
This is invaluable when troubleshooting VMs that won't boot or are crashing repeatedly.
If you've worked through all seven steps and the VM still isn't responding, you've done the right investigation. Document what you've checked, screenshot the error messages or logs, and hand it over to a senior engineer. You've already ruled out 90% of common issues, which saves them hours.
Learning to troubleshoot Azure VMs is one of the core skills you'll need as you move into cloud infrastructure roles. If you're planning a career move into Azure administration or cloud engineering, understanding these troubleshooting patterns now makes the difference between getting frustrated and actually progressing.
The Azure Administrator Programme at SmoothOps 365 covers not just VM creation but real-world troubleshooting, network security, and performance tuning. If you're planning to move into this space and want structured, hands-on training, you can explore that on smoothops365.com/courses or book a free 2-hour live session to see how we teach cloud troubleshooting in practice: smoothops365.com/courses/it-helpdesk#free-session.
A deallocated VM is switched off and not consuming compute resources, so you're charged only for storage. You won't be charged for the VM's running time. When deallocated, the VM is completely unresponsive and won't answer any connection attempts. To use it again, you must click Start in the portal and wait for it to reach "VM running" status.
After starting a deallocated VM, wait 60 to 90 seconds for it to fully boot and allocate resources. If you've waited two minutes and still can't connect, move on to checking network rules. Don't assume it's broken within the first minute.
Many issues (NSG rules, public IP assignment, firewall rules) can be fixed without restarting. Resource exhaustion and boot errors usually require a restart or VM resize. Always try non-destructive troubleshooting steps first, then restart if needed.
An NSG blocks traffic before it reaches the VM's network interface, like a perimeter fence. The OS firewall (Windows Defender Firewall or iptables) is on the machine itself and blocks traffic after it arrives. Both must allow your traffic for a connection to work.
Check the Boot Diagnostics section in the Azure Portal for screenshots and serial logs. You can also look at the VM's Activity Log to see Azure-level errors. The serial console shows operating system level errors. Between those three, you'll find the root cause.
SmoothOps 365 runs live instructor-led training every Saturday and Sunday. 3 months. 50 contact hours. Keep your job while you train.