Stop Compute Engine VMs at Night with Instance Schedules

Compute Engine has a native way to do this: an instance schedule, which is a resource policy that holds a start cron and a stop cron and is attached to VMs in the same region. This guide builds one from the command line, attaches it, and checks that it fired.

What you need first

• The gcloud CLI, authenticated against the project.
• For yourself: the Compute Instance Admin (v1) role (roles/compute.instanceAdmin.v1) or a custom role with compute.resourcePolicies.create, compute.resourcePolicies.use and compute.instances.addResourcePolicies.
• For the Compute Engine Service Agent (not your user): roles/compute.instanceAdmin.v1 on the project. The schedule runs as this agent, and it needs compute.instances.start and compute.instances.stop. If that grant is revoked later, the schedule silently stops working.

1. Check for Local SSD

Instance schedules cannot stop a VM that has Local SSD disks attached. List what each candidate carries:

gcloud compute instances describe dev-api-01 --zone=europe-west2-b \
  --format="table(name,disks[].type,disks[].interface)"

A VM with SCRATCH disks needs a different approach: stop it yourself with gcloud compute instances stop dev-api-01 --zone=europe-west2-b --discard-local-ssd=true (the data is gone), or copy the data to a persistent disk first. Stopping from inside the guest OS also discards Local SSD data.

2. Create the schedule

Crons run in the IANA zone you pass. Google warns that an operation can start up to 15 minutes after its scheduled time, so set start and stop 15 minutes earlier than you need, and keep the two at least 15 minutes apart.

gcloud compute resource-policies create instance-schedule office-hours-ldn \
  --region=europe-west2 \
  --vm-start-schedule="45 7 * * 1-5" \
  --vm-stop-schedule="45 18 * * 1-5" \
  --timezone="Europe/London"

Optional --initiation-date and --end-date bound the schedule, for example to a project that ends next quarter.

3. Attach VMs

The VM must be in the schedule’s region. Each VM can follow only one instance schedule; one schedule can cover up to 1,000 VMs.

gcloud compute instances add-resource-policies dev-api-01 \
  --resource-policies=office-hours-ldn \
  --zone=europe-west2-b

Attaching a schedule does not act immediately. A VM attached at 16:00 to the schedule above stays as it is until the next scheduled operation.

4. Verify the first run

After 19:00 the VM should report TERMINATED:

gcloud compute instances describe dev-api-01 --zone=europe-west2-b \
  --format="value(status,resourcePolicies)"

Google’s guidance is to check the audit logs for both the resource policy and the VM, because a failed schedule does not alert on its own.

What a stopped VM still costs

A stopped VM keeps its attached disks, configuration and metadata. Compute Engine charges vCPU and memory only while the VM is running (or in PENDING_STOP), but attached disks and external IP addresses bill for as long as they exist, whatever the VM state. The overnight saving is the machine rate for the hours off, not the whole line item.

To undo, detach the policy with gcloud compute instances remove-resource-policies dev-api-01 --resource-policies=office-hours-ldn --zone=europe-west2-b.

Where ZopNight fits

Instance schedules are per region and per VM. ZopNight can start and stop Compute Engine VMs across projects from one schedule defined with cron expressions and an IANA timezone, attached to single VMs or to a resource group. The GCP account needs read + write permission for that; a read-only connection still gives discovery and recommendations. See Compute Engine scheduling for the resource specifics, and cron scheduling if the expressions above are new.