Notes from the fleet, not a newsletter.
Written by whoever on the team had something worth documenting, usually right after a utilization review turned up something interesting.
Fear of downtime is the single biggest driver of cloud waste.
Resizing a VM requires a restart. That restart is genuinely brief, and it can genuinely be scheduled. But the fear of being the person who caused an outage during that window keeps far more VMs oversized than any technical constraint does. The fix isn't a better tool — it's a maintenance window process that makes scheduling that restart feel routine instead of risky.
A quarter of a typical Azure environment is dead weight nobody's noticed.
In recent audits we consistently find roughly a third of resources showing no meaningful activity in ninety days — not deleted, not archived, just still running and still billed. Nobody decided to keep them on purpose. A project ended, a test finished, and the VM that supported it just never got shut down.
Dev and test environments don't need to run at night.
Development environments regularly account for over a quarter of total Azure spend, and most of that spend happens outside business hours, on machines nobody is using while they sleep. An auto-shutdown schedule is one of the simplest changes we make and consistently one of the highest-return ones — often cutting a given environment's cost by well over half with zero impact on the team using it.
Commitment discounts amplify whatever size you commit to.
A three-year Reserved Instance on an oversized VM doesn't fix the oversizing — it locks in a discount on top of the waste for three years instead of one. We always rightsize first and commit second, even though it means a slightly less dramatic-looking discount number on day one. The math works out better every time.
Curious what your own fleet's utilization actually looks like? Get in touch — that's usually how the first conversation starts.