Compute Engine VMs averaging under 5% CPU for 30 days
What does ZopNight detect here?
Compute Engine charges running VMs for every vCPU and GB of memory, so a VM averaging under 5% `CPUUtilization` for 30 days is mostly paid-for idle. ZopNight either prices an off-hours schedule from the VM's measured idle share or, when the VM is quiet nearly all the time, flags its full compute cost for review before stopping.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-102 |
| Category | schedule |
| Severity | medium |
| Metric | CPUUtilization |
| Threshold | average CPU under 5% |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | compute.instances.list · compute.instances.get · monitoring.timeSeries.list |
Where it applies
Low CPU does not mean low cost
A running VM is billed for its machine type every hour, regardless of load. Cloud Monitoring’s
compute.googleapis.com/instance/cpu/utilization is the hypervisor’s view of how much allocated
CPU the VM actually uses, per the
Compute Engine metrics list. A month of
single-digit readings usually means the VM is either needed only part of the day or not needed at
all.
Checking CPU on a VM
gcloud compute instances list --filter="status=RUNNING" \ --format="table(name,zone,machineType.basename(),creationTimestamp)"Chart CPU and the network in and out metrics for a candidate over 30 days. A daily hump means a schedule; a flat line means review.
Two outcomes from one CPU test
ZopNight reads 30 days of CPU by name and requires an average under 5%. From there:
- Quiet nearly all the time. When the hourly readings show the VM idle at least 95% of the time, across at least a week of hours, and average network traffic stays under 1 MB per measurement interval in each direction, ZopNight raises a review-then-stop finding.
- Quiet part of the week. Otherwise it uses the VM’s usage heatmap to find an off-hours window and proposes a recurring schedule.
Signals that stop or soften the finding
A VM with a schedule label is treated as already parked. Names with a dr or standby token,
which mark disaster recovery capacity, and self-managed databases, caches or brokers, are excluded. For the
near-idle case, peaks that recur at the same hour each week, sustained network bursts, and
access-infrastructure names such as bastions also veto it, and peaks clustered at month end turn
the advice into “check the month-end batch first”. Without a price, or without schedule data in
the second case, there is no finding.
Two ways the saving is priced
near-idle: saving = full monthly VM cost (compute only)scheduled: saving = monthly VM cost x measured off-hours idle sharePersistent disks and static IPs bill separately and are not in either figure.
Acting on an idle VM
ZopNight does not stop these VMs automatically; the finding is advice for you to act on.
- For the scheduled case, review the proposed start, stop and time zone, then apply it from the recommendation as a recurring off-hours park.
- For the near-idle case, confirm with the owner that nothing runs on it, then stop it:
gcloud compute instances stop VM_NAME --zone=ZONE. - After a quiet period stopped, snapshot and delete it, which also ends its disk charges, as covered by Stopped Standalone GCE VM.