Skip to main content
Back to the Azure Footguns Database
ReliabilityGovernanceLowCommonAZF-0079

Boot diagnostics disabled: when the VM won't start, you're debugging a black box

Boot diagnostics is off unless someone turned it on, and you discover that at the worst possible moment: mid-outage, staring at a VM that won't boot and produces no evidence about why.

Footgun ID
AZF-0079 (Azure Footgun No. 79)
Azure service
Azure Virtual Machines
Resource type
Microsoft.Compute/virtualMachines
Updated
July 9, 2026

What it is

A virtual machine with diagnosticsProfile.bootDiagnostics.enabled not set to true. Boot diagnostics captures a console screenshot and serial log during startup — the only window into a VM that hangs before the OS (and therefore SSH, RDP, and every monitoring agent) comes up. With it disabled, a failed boot after a patch, resize, or unplanned host move gives you exactly nothing to work with.

Impact (reliability)
A boot failure with no console screenshot or serial log — recovery becomes guesswork while the outage clock runs
Basis: Azure behavior (authored assessment). Figures are estimates, not measurements.

Why it happens

Boot diagnostics is off unless explicitly enabled, and many ARM templates, Terraform modules, and image pipelines never set it — it's a nice-to-have that adds nothing on the happy path, so it gets skipped. The portal enables it for portal-created VMs, which makes coverage inconsistent: hand-made VMs have it, the infrastructure-as-code fleet often doesn't.

The trap has a nasty asymmetry: the setting only matters when the VM is already unbootable, and that's precisely when you can no longer turn it on and see what happened. The evidence you needed was never captured. Everything before that moment looks fine, so nothing prompts anyone to check.

What it costs / blast radius

With the managed storage option, boot diagnostics costs effectively nothing — no storage account to maintain, no meaningful line on the bill. This is pure operational insurance. What's at stake is incident time: a VM stuck at boot with diagnostics enabled shows you the kernel panic, the BSOD stop code, or the fsck prompt in one screenshot; the same VM without it is a black box you resort to detaching disks and rebuilding around, while the outage runs. The check is hygiene, but the moment it matters, it really matters. (Authored assessment of Azure behavior.)

See it

Footgun: boot diagnostics off — a failed boot leaves no evidence
resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: 'app-vm-01'
  location: location
  properties: {
    hardwareProfile: { vmSize: 'Standard_D4s_v5' }
    // ...osProfile and networkProfile omitted for brevity
    // diagnosticsProfile omitted: no console screenshot,
    // no serial log when this VM fails to start
  }
}
Fix: enable it with managed storage (no storageUri needed)
resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: 'app-vm-01'
  location: location
  properties: {
    hardwareProfile: { vmSize: 'Standard_D4s_v5' }
    // ...osProfile and networkProfile omitted for brevity
    diagnosticsProfile: {
      bootDiagnostics: {
        enabled: true   // omit storageUri to use managed storage
      }
    }
  }
}

How StratoLens helps

StratoLens flags every VM with boot diagnostics disabled, continuously and across all your subscriptions, so the gap surfaces during a calm Tuesday review instead of during the outage. It's the kind of setting nobody audits by hand — which is exactly why the check runs automatically.

Start Your 28-Day Free Trial

Every feature unlocked. Deploys to your Azure tenant. No data leaves your tenant.

Available now on the Azure Marketplace.

Not ready to install anything? Browse the Azure Footguns Database: 55+ documented ways Azure quietly costs money or creates risk.

Request a demo

StratoLens catches the cost waste, access risk, and config drift across your whole Azure estate, from inside your own tenant, so your data never leaves it.