GCP Instance Schedules Alternative: Limits and ZopNight
Compute Engine's built-in schedules are free and simple, but they come with a specific set of limits. Here they are, from Google's docs.
How Compute Engine instance schedules work
An instance schedule is a resource policy. You “create a resource policy detailing the start and stop behavior, and then attach the policy to one or more VM instances” (Google Cloud docs). Unlike Azure’s per-VM auto-shutdown, a single schedule does both start and stop.
The same page documents the limits that matter in practice:
- One region. A schedule and its VMs must be in the same region.
- One schedule per VM, and “up to 1,000 VM instances” per schedule.
- Timing. An operation “might take up to 15 minutes past the scheduled time”, so start and stop operations should be at least 15 minutes apart.
- Local SSD. You “can’t use instance schedules to stop an instance that has Local SSD disks”.
- No capacity guarantee when a VM starts.
- Permissions. The Compute Engine Service Agent needs
roles/compute.instanceAdmin.v1, or “your instance schedules might stop working without notice”.
For managed instance groups, Google points to scaling schedules instead. It also offers VM run-time limits that stop or delete a VM after a set duration.
When instance schedules are enough
For a handful of Compute Engine VMs in one region, on a fixed weekday window, instance schedules cost nothing extra and need no other tooling. Grant the service agent role first, since a missing role is the documented way for schedules to fail silently.
Where ZopNight differs
- Beyond Compute Engine. ZopNight schedules Cloud SQL, GKE clusters and node pools, GKE Deployments, StatefulSets and CronJobs, and whole Kubernetes namespaces, on the same schedule as your VMs. See Cloud SQL scheduling and GKE scheduling.
- Across regions and projects. A ZopNight schedule is not tied to one region. Attach resources from any connected GCP project, or from AWS and Azure accounts.
- Failures you can see. Start and stop actions report their status. Failures show in the UI and can notify Slack, Teams, Google Chat or a webhook, and each state change records what triggered it. For VM-specific details, see Compute Engine scheduling.
- Cost from your billing export. GCP cost comes from the BigQuery billing export, net of credits, so committed-use and sustained-use discounts show the way your invoice bills them.
| ZopNight | Compute Engine instance schedules | |
|---|---|---|
| Resource types | VMs, Cloud SQL, GKE, K8s workloads and namespaces | Compute Engine VMs |
| Region scope | Any connected project and region | Same region as the schedule |
| Schedules per VM | One scheduling source per resource | One |
| Failure visibility | Action status plus notifications | Can stop silently if the service agent role is missing |
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Can Compute Engine instance schedules handle Cloud SQL?
No. Instance schedules are resource policies attached to Compute Engine VM instances. Cloud SQL needs another mechanism. ZopNight schedules Cloud SQL alongside VMs.
Why did my GCP instance schedule stop working?
Google's documentation warns that if the Compute Engine Service Agent lacks roles/compute.instanceAdmin.v1, instance schedules might stop working without notice. Check that role first.
Is there a limit to how many VMs one schedule covers?
Google documents up to 1,000 VM instances per instance schedule, all in the same region, with each VM on at most one schedule.