Gonzalo Gjuka

Agreed on the stopped VMs. The confusing part is that az vm list-usage lumps them into "Current in use", so the number looks right until you remember the three deallocated test boxes from last month. What helped me was listing them explicitly before asking for more quota: az vm list -d --query "[?powerState=='VM deallocated'].{n:name,size:hardwareProfile.vmSize}" -o table. Deleting two of those freed the family quota in minutes; the increase request would have taken a day. Which family did you hit it on?

The forgotten tab has a cousin in Azure SQL serverless: the auto-pause delay defaults to 60 minutes (15 is the floor, same as Fabric), and any login or activity resets the clock, so a health check every 30 minutes keeps the database billed around the clock while looking idle. Checking who still connects is part of the fix, not only the workload.

"Watch the cleanup side of retention" applies one level up too. On Azure the managed disks that back PVCs have a diskState worth reading before trusting a count: Unattached is the real orphan; Reserved means the disk belongs to a stopped-deallocated VM and comes back on Start; ActiveSAS means someone ran az disk grant-access and is exporting the VHD. The portal-style check "managedBy is null" lists the last two as free to delete; az disk list --query "[?diskState=='Unattached'].[name,diskSizeGb,lastOwnershipUpdateTime]" -o table does not. Same pattern as your snapshots: the object that "works" for days is the one whose delete path nobody exercised, so the inventory is the test.

"Online 97% of the time for two CPU-minutes of work" is the same arithmetic that bites on plain VMs: with a 12-hour weekday window a machine is used 60 of the 168 hours in a week and could be off for 108, 64%. The part worth underlining for anyone copying the fix is the dependency: stopping the thing that polls does nothing for the thing it kept awake. Outside Fabric the "does not stop when you stop the workers" list is short: managed databases (a stopped RDS instance restarts itself after seven days), load balancers and NAT gateways billed per hour of existence, disks, public IPs. Sorting the bill by item, as you did, is the only way those show up.

For these windows or gaps, there are scheduled tasks or commands in place to verify specific metrics or actions within the provider environment. This process generates an alert, which is linked to a corresponding metric; if either one provides a response, it indicates that the resource is operational or that the metric is accurate. This is evaluated from two perspectives: if the alert returns a 200 status code, it suggests an issue with the metric; conversely, if the metric returns a 200, it confirms that the alert is active and the outcome is correct, as the equipment is reporting its status via that metric. This approach also helps in addressing false positives and connectivity issues, as they can be analyzed from multiple angles.