What it is
An Azure reservation (or savings plan) whose matching usage has drifted below what you committed to. Reservation discounts are use-it-or-lose-it on an hourly basis: every hour the reservation isn't fully applied to running resources, the unused portion of that hour's commitment is simply gone. The bill looks normal — you're paying exactly what you agreed to — which is why nobody notices.
Why it happens
Reservations bill the full commitment regardless of whether anything consumes the discount. The benefit applies hour by hour to matching resources, and unused hours do not roll over.
Utilization drifts down for mundane reasons: VMs get resized to a different family the reservation doesn't cover, workloads move regions, dev environments gain deallocation schedules, or the reservation's scope is pinned to a single subscription while matching VMs now run in another one. Each change is individually sensible; none of them triggers any warning that a commitment elsewhere just lost its match.
Azure's utilization data exists, but it lives in a corner of Cost Management that someone has to remember to open — there is no default alert when a reservation sags to 60%.
What it costs / blast radius
The waste is a billing identity, not a guess: monthly waste = monthly commitment × (1 − utilization%). A reservation costing $10,000/month at 60% utilization wastes ~$4,000/month, about $48,000/year, while the invoice total looks exactly as expected. (Authored estimate from Azure billing mechanics; your commitment amounts and rates are your own.)
The insidious part is the direction of the error: an underutilized reservation never shows up as a cost spike. It shows up as savings you thought you were getting and weren't.
See it
# List reservation orders, then pull utilization summaries
az reservations reservation-order list \
--query "[].{name:displayName, orderId:name, term:term}" -o table
az consumption reservation summary list --grain monthly \
--reservation-order-id <order-id> \
--query "[].{month:usageDate, utilization:avgUtilizationPercentage}" -o table
# Anything persistently below ~85% is burning committed spend# Often the cheapest fix: broaden scope so any subscription can consume it
az reservations reservation update \
--reservation-order-id <order-id> --reservation-id <reservation-id> \
--applied-scope-type Shared
# If the workload is truly gone: exchange the reservation for a SKU/region
# you do run, or request a refund (both via the portal's Exchange/Refund flow,
# subject to Azure's exchange and refund policies).How StratoLens helps
StratoLens tracks utilization for every reservation and savings plan across your subscriptions and flags the ones running below threshold, with the projected monthly waste attached. The check runs continuously inside your own tenant, so a commitment that quietly lost its workload gets surfaced instead of renewing by habit.