An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.
Hello Charles Daniels - Admin
Thank you for the details.
The "Unhealthy" status you're seeing is an application-level health signal, not an indication that the VM itself is down. Azure marks an instance Unhealthy when the configured health probe (either the Application Health Extension or a Load Balancer health probe) does not receive a valid response on the configured port or request path — even if the VM is fully booted and otherwise operational. For HTTP/HTTPS probes, only an HTTP 200 response is treated as healthy.
The most common cause of this exact pattern — VM restarts, comes back up, but stays Unhealthy — is that the application or service listening on the probe port did not start automatically after the reboot, or started in a failed state.
Could you please help us with the following so we can confirm the cause:
- A screenshot showing where the "Unhealthy" status is displayed (VM blade, scale set instance list, or Load Balancer backend health).
- The health probe configuration in use: protocol, port, request path, interval, and threshold.
- From inside the VM, the output of:
- Windows: netstat -an | findstr <probePort>
- Linux: ss -lntp | grep <probePort> The probe port must be in a LISTENING state.
- If an HTTP/HTTPS probe is configured, the output of curl -v http://127.0.0.1:<port>/<path> from inside the VM — we need to confirm it returns HTTP 200.
- The NSG rules applied to the VM's NIC and subnet. Health probes originate from the Azure platform IP 168.63.129.16, and this address must be allowed inbound on the probe port.
- System and Application event logs (or journalctl -b -1 on Linux) covering 30 minutes before and after the restart.
- The exact date, time, and timezone of the restart, along with the VM name, resource group, and subscription ID.
- Windows: netstat -an | findstr <probePort>
In parallel, please also review VM > Resource health > Health history in the portal for the time of the restart. The annotation there will tell us whether the reboot was initiated by the platform, by a user, or from within the guest OS.
Once we have this information, we can confirm the root cause and provide the corrective action.
Thanks,
Suchitra.