How To Architect on Azure: Uptime Is the Wrong Humble-Brag
A virtual machine we run had been up for more than a quarter without a reboot. We were quietly proud of it. Then we measured it, and the number we were proud of turned out to be the least useful number on the page.
This is how we troubleshoot, which Azure features keep a machine honest for free or close to it, and why we no longer put uptime on the wall.
What an uptime number actually tells you
Uptime is the time since somebody last looked. It does not tell you the machine is healthy. It tells you nothing has forced a change.
Three things hide inside a long uptime:
A stale kernel. Kernel updates take effect at reboot. A box that never reboots keeps running yesterday's kernel while the package manager reports that everything is installed.
An untested boot path. Mount tables, network configuration, ephemeral disks and service ordering are only exercised at boot. A machine that has not booted in a quarter has a quarter of untested assumptions.
A growing gap between the state you think it is in and the state it would come back in. The longer the gap, the more surprising the first reboot.
We met the third one directly. When we finally changed that machine's size, the reboot surfaced two boot-time surprises that a monthly cadence would have shown us in small, boring doses. There was about a minute of planned downtime, plus one self-inflicted mount mistake that hid some files for a couple of minutes before we caught it. We were glad we had snapshotted first.
What belongs on the wall instead is time to detect, time to restore (tested, not assumed), patch age, the age of your last restore test, and change failure rate. If you track the four DORA metrics, be honest about the ones you cannot measure yet. We can measure two of the four on our own pipeline, and the other two say unknown, because only a fraction of our deploys had been recorded. A rate with no denominator is not a rate.
How we troubleshoot
The rule we repeat to each other is the Jedi one: do not fix it until you know what is broken. In practice that is seven habits.
State the symptom as a measurement. Not "search feels slow" but "the 95th-percentile wait is above its limit while utilization is low." Those point at different problems. Low utilization with long waits means requests are queued behind something, not that the machine is too small.
Ask the cheapest question first. Platform metrics are free. Read them before you design anything.
Check the layer above the one you are tuning. We were about to stripe several disks together for more throughput. The numbers said otherwise (the figure below). Every disk was under its own ceiling, and the only thing at 100 percent was the limit the VM size puts on all of its disks combined. Striping raises the disk ceiling. It cannot raise the VM's.
Write hypotheses as hypotheses. We believe that cap caused the long waits. We have not proven it, and our notes say so until we have measured the same wait after the change.
Make the first change reversible. A resize can be undone with one command. A disk rebuild cannot.
Check the guardrails before you press the button. Generation, static public IP, resource locks, the sizes Azure will allow, and quota. Our first attempt was refused at validation because the subscription's quota for that VM family was zero. Nothing changed, which is exactly what a refused validation is for. We had been thorough about quota once, long ago. Quota is a thing you audit again.
Verify by the artifact, not the exit code. Count the documents before and after. Check each mount. Hit each endpoint. A command that returned success told you it ran, not that the machine is right.
Free and near-free Azure features that keep you honest
Prices change, so confirm on Microsoft's pricing pages. As of this week, from Microsoft's own documentation:
Platform metrics. Free, and retained for 93 days. Look past CPU and disk to the VM-level metrics for uncached disk bandwidth and IOPS consumed. They report how close the VM is to its own cap. Metric alert rules have a small free allowance and then bill per monitored time series, so check the current rate before you alert on a fleet.
Activity log, Service Health and Resource Health alerts. The rules are free. Email is the cheap notification channel; SMS and voice are billed. The CIS Microsoft Azure Foundations Benchmark expects a Service Health alert to exist.
Azure Advisor. Free, with no SLA. Acting on a recommendation can cost money (turning on backup, for example), so read the recommendation before you click.
Azure Update Manager. Free for Azure VMs. Arc-enabled servers outside the exempt cases are billed per server per month, per Microsoft's FAQ.
Defender for Cloud foundational posture. Free. Starting late October 2026 it is opt-in for new subscriptions instead of on by default, so turn it on deliberately.
Incremental snapshots. You pay for changed blocks, not a full copy. Take one of every disk before any change, then prove it restores: create a disk from the snapshot, compare its size in bytes to the source, delete the test disk. That proves the block copy. A full drill on a scratch machine proves the rest, and it deserves a calendar date.
Resource locks. No charge, and they stop the expensive mistake.
Quota usage alerts. Azure's own refusal message told us to set them. Audit quota for the families you might need to move to, and ask early.
Maintain the compute, because the compute is the product
It is tempting to treat the VM as a fixed fact and tune everything above it. Three lessons from tending ours:
Match the family to the workload. Burstable families are excellent for spiky work and have low sustained disk limits. A database that indexes all day is a sustained workload. The right family for it was not the cheapest one, and it was not much more expensive either.
Ephemeral disks wipe on resize and redeploy. Many VM sizes include a temporary disk. Anything mounted beneath it, including the empty directories you attach other disks to, disappears with it, and a mount marked nofail fails in silence. Keep mount points off ephemeral storage, or add the x-systemd.mkdir mount option so systemd recreates them.
Mount order matters, and the mount command that mounts everything follows file order. If the parent mounts last it hides the children, and they look empty. Put the parent first in the file. Then check each mount by itself, because asking for several at once can print nothing and look like success.
Best practice, and where we are against it
The yardstick is the Azure Well-Architected Framework, the Microsoft cloud security benchmark and the CIS Azure Foundations Benchmark. They agree on the shape: define recovery targets and test them, patch on a schedule, alert on platform health, and put redundancy in front of anything customers depend on.
Where we stand, in plain terms: we test restores before changing anything, and we have a written runbook with a monthly patch window planned and not yet on the calendar. Where we have not built redundancy yet, we write the risk acceptance down with a date instead of pretending the gap is closed. Our full recovery drill is due again, and that is on our list.
Compliance, as percentages
Self-scored, not audited. None of this is a certification.
FDA premarket cybersecurity readiness checklist: 95% now, target 95%. That is also our ceiling. We do not claim 100%, because something is always wrong somewhere. The external test that would make this number mean more has not happened yet.
SOC 1-style control self-score: 81% now, target 95%.
SOC 2: no report exists, and a self-assessment cannot create one. So there is no percentage here and no claim of compliance.
NIST 800-171: we hold a self-assertion that we have not re-verified, so we do not quote it.
The checklist
Alert on Service Health and on the VM-level cap metrics, not only CPU.
Snapshot every disk and restore-test one before any change.
Audit quota for the VM families you might move to.
Pick the family for the workload, and revisit it when the workload changes.
Patch and reboot on a schedule, and record both.
Keep mount points and state off ephemeral disks, and check each mount after every boot.
Write hypotheses as hypotheses until you have measured the change.
Replace uptime on your dashboard with time to restore.
Sources: Microsoft Learn on the Azure Update Manager FAQ, the Defender for Cloud posture management concepts, and the Azure Advisor product page, all read October 29, 2026. Pricing and defaults change, so check them again before you rely on them.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post — the widget is at the bottom of the page, and we read every response.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Comments