Scheduling non production environments off on GCP.

This is low risk because nothing here serves customers. Here is how to capture it cleanly.

How much does scheduling non production actually save?

The arithmetic is the whole argument. A week is 168 hours. An environment that engineers use during business hours, roughly 10 hours a day across 5 days, needs about 50 hours. Stopping the remaining 118 hours removes about 70 percent of compute time. Push further to an on demand model, where machines start only when someone needs them, and you can remove 85 percent or more.

Across many dev, test, and staging environments that compounds into one of the cleanest savings on the bill, because none of it touches production.

What mechanisms can schedule GCP environments off?

GCP gives you several, matched to the resource.

Instance schedules are resource policies that automatically start and stop Compute Engine VMs on a recurring cron, the simplest native option for plain VMs. Attach a schedule to the machines and they cycle without any code.

Cloud Scheduler with Cloud Functions handles anything more bespoke: start and stop logic that depends on conditions, batched fleets, or coordination across services. It is the flexible option when a plain cron is not enough.

GKE node pools are scaled down or to zero on a schedule rather than stopped, since Kubernetes manages the nodes. Combine a scheduled scale down of non production node pools with the cluster autoscaler so capacity returns when work arrives. This sits alongside the broader container picture in the multi tenant cluster economics discussion.

Cloud SQL instances can be stopped to halt their compute charge, useful for non production databases that nobody queries overnight.

What still bills when a GCP instance is stopped?

Stopping is not deleting, and several resources persist and keep charging.

Persistent disks keep billing. A stopped VM still has its boot and data disks, which are storage and charged regardless of instance state. Boot disk hygiene matters here, the same point made in cleanup discipline across clouds.

Reserved static IP addresses keep billing. A static external address is charged whether or not it is attached to a running instance.

Committed use discounts keep billing. A CUD bills for its term whether the covered machine runs or not, which is exactly why non production should stay off commitments and rely on the schedule instead, in line with the risk adjusted approach to GCP commitments.

Stopping reduces sustained use discounts. Because sustained use discounts reward running most of the month, a machine you stop two thirds of the time earns little or none. That is fine: you are trading a modest automatic discount for removing most of the cost, which is a far bigger saving. Do not let the lost sustained use discount talk you out of the schedule.

A worked example: a scheduled non production estate

How should you roll this out safely?

Automate it and make it reversible. Tag environments that are safe to stop, attach instance schedules or Cloud Scheduler jobs, scale GKE node pools rather than stopping nodes, and always give engineers a self service way to start something outside the schedule so the policy never blocks real work. Keep non production off committed use discounts so the schedule captures the full saving. This is one of the fastest wins in the GCP cost optimization guide.

Get the buyer side GCP waste playbook

We put GCP non production on a schedule your engineers will accept, keep it off commitments, and capture the full saving with zero provider commissions. It is the same discipline behind the 31 percent median reduction we see in the first 90 days. Our guarantee: we reduce your cloud spend or we reimburse our service fee.