Azure Documented How Your VMs Die — but Not When. Here's How to Catch Surprise Reboots in Minutes

Microsoft just published documentation defining the full lifecycle of an Azure virtual machine — every state a VM moves through from creation to deallocation, including what happens during platform maintenance and host failure. Read it closely and you'll notice what's missing: timing. No maintenance windows. No notice periods. No estimate of how long your VM will be down when the platform decides to bounce it.

If you run production workloads on Azure — SQL, a domain controller, a line-of-business app host — you already know how this plays out. Azure reboots your VM when the platform needs it to, and you find out when a user calls. You can't control when it happens. What you control is how fast you detect it, verify your services survived, and fix what didn't. That's a tooling problem, and most IT teams are losing that fight across four disconnected consoles.

The 66-Minute Reboot Nobody Saw Coming

Tuesday, 10:14 AM. Azure host maintenance quietly restarts your production SQL VM. SQL Server comes back up. SQL Server Agent — set to delayed automatic start, because someone read a blog post about memory pressure in 2022 — does not.

Here's what happens next in a typical IT shop:

• 10:14 — VM reboots. Your standalone monitor (PRTG, Zabbix, Azure Monitor) blips a heartbeat alert that auto-closes ten minutes later when the host comes back.
• 10:52 — A user opens a ticket: the reporting portal is empty. Nobody connects it to the reboot.
• 11:05 — A tech opens the helpdesk, then the Azure portal to check the Activity Log, then the RMM console to remote in, then restarts SQL Agent by hand.
• 11:20 — Fixed. Five consoles, 66 minutes, three people, and no single record connecting the alert, the cause, and the fix.

Multiply that across every Azure VM, every on-prem server, every client an MSP supports. This is why MTTR sits at an hour for events that should take ten, why SLA reports never match reality, and why your best tech is interviewing elsewhere.

What Microsoft Actually Told You

Credit where due: the lifecycle documentation is genuinely useful. It defines the states — Creating, Starting, Running, Stopping, Stopped, Deallocating, Deallocated — and what forces transitions: host OS patching, hypervisor upgrades, hardware degradation. Azure's Instance Metadata Service (IMDS) even exposes Scheduled Events so a VM can ask what's coming.

But look at the fine print: for some event types you get minutes of warning via IMDS, and for unplanned host failures you get none. Microsoft is telling you how your VM dies. The when — and everything that happens in the fifteen minutes after it comes back — is still your problem. The lifecycle doc describes the states. It does not run your post-boot checks.

Why Fragmented Tooling Turns a 2-Minute Event Into a Ticket Pile

The gaps here aren't a skills problem. They're architectural:

• Monitoring doesn't know about Azure maintenance. Your standalone monitor sees heartbeat loss and recovery. It can't tell a platform reboot from a genuine crash, so it either cries wolf or stays silent.
• The RMM isn't triggered by the alert. NinjaOne or ConnectWise can absolutely run the script that verifies and restarts your critical services — but nothing connects "this VM just rebooted" to "run that script now." A human has to notice, remember, and switch tabs.
• The helpdesk is blind. The ticket says the portal is empty. It has no link to the reboot alert, the Azure event, or the commands the tech ran. Post-incident review is archaeology across four systems.
• Nobody can answer the manager's question. How long was SQL Agent actually down? When did we detect it? What did we do? That answer lives in three tools that don't talk, which is why the SLA report is a guess.

The real cost of this pattern is not the two minutes of actual downtime. It's the hour of human time, the escalated tickets, the missed SLA credits for MSPs, and the technicians who are tired of being the integration layer between their own tools.

How AlertMonitor Closes the Gap

This is exactly the workflow AlertMonitor was built for: monitoring, RMM, helpdesk, and patching in one platform, on one timeline.

• One agent, one console. The same platform watching the VM's heartbeat also runs RMM. When the VM reboots, AlertMonitor correlates the Windows event log (Kernel-Power 41, Event 6008, Event 1074) and raises an unexpected reboot alert that doesn't auto-close until someone — or a policy — has verified the system.
• Scripts run from the alert, not from a separate tool. Open the alert, run the post-boot service verification script against the device group, see the output inline. Script results feed back into the monitoring timeline, so the remediation lives in the same record as the alert.
• Auto-remediation policies. On unexpected reboot: run the service check script, restart any stopped critical services, auto-create a ticket with the script output attached. Total human involvement: reviewing what the system already did.
• Helpdesk in the loop automatically. The user's ticket, the reboot alert, and the remediation actions all link to one incident. Your SLA report writes itself, because detection time and resolution time come from the same system.

Same Tuesday morning, on AlertMonitor:

• 10:14 — VM reboots. Unexpected reboot alert fires.
• 10:15 — Auto-remediation policy runs the service check. SQL Agent is stopped; the script starts it; output is logged and the incident record is annotated automatically.
• 10:16 — The user submits a ticket and gets an immediate answer: known event, already remediated, monitoring for recurrence.
• 10:20 — A tech reviews the timeline for 90 seconds. Done. Two minutes of actual downtime, five minutes of human attention, one record.

Practical Steps You Can Take Today

Even before you change platforms, put these scripts on every Azure VM. They're the difference between knowing and guessing.

1. Detect unexpected reboots on Windows (last 24 hours):

# 41 = Kernel-Power (unexpected loss), 6008 = dirty shutdown, 1074 = restart initiated by user/process
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 41, 6008, 1074
    StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Id, ProviderName,
    @{N='Detail';E={ $_.Message.Substring(0, [Math]::Min(120, $_.Message.Length)) }} |
  Sort-Object TimeCreated | Format-Table -Wrap

2. Ask Azure itself what maintenance is pending (IMDS Scheduled Events):

$imds = Invoke-RestMethod -Headers @{ 'Metadata' = 'true' } `
  -Uri 'http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01'
$imds.Events | Select-Object EventId, EventType, ResourceType, NotBefore

On Linux VMs:

curl -s -H Metadata:true \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" \
  | jq '.Events[] | {EventId, EventType, ResourceType, NotBefore}'

3. Post-boot verification and recovery of critical services:

$critical = @('MSSQLSERVER', 'SQLSERVERAGENT', 'W3SVC', 'DNS', 'Netlogon')
foreach ($name in $critical) {
    $svc = Get-Service -Name $name -ErrorAction SilentlyContinue
    if (-not $svc -or $svc.StartType -eq 'Disabled') { continue }
    if ($svc.Status -ne 'Running') {
        Start-Service -Name $name -ErrorAction SilentlyContinue
        $svc.Refresh()
    }
    '{0,-18} {1}' -f $name, $svc.Status
}

4. Wire it into AlertMonitor. Deploy script #3 to your Azure-Production-VMs device group, then create an auto-remediation policy: trigger on unexpected reboot, run the script, attach the output to the auto-created ticket. From then on, every platform maintenance reboot resolves itself, and your techs only see the exceptions.

5. For Linux workloads, verify service state the same way:

for svc in nginx mssql-server; do
  systemctl is-active --quiet "$svc" || sudo systemctl start "$svc"
  printf '%-15s %s\n' "$svc" "$(systemctl is-active "$svc")"
done

You Can't Control When Azure Reboots You. You Can Control the Next 10 Minutes.

Microsoft's documentation answers "how" and stays silent on "when," and that's not changing — cloud providers optimize for their fleet, not your maintenance calendar. The IT teams that come out ahead are the ones who stopped treating platform reboots as surprises and started treating recovery as an automated, logged, measurable workflow.

That means detection that fires on the reboot itself, remediation that runs without waiting for a human to open four consoles, and one timeline that shows the alert, the action, and the ticket together. That's what unified monitoring and RMM is actually for — and it's the difference between a 66-minute incident and a 90-second review.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources