Scheduling Compute Engine Instance
Can ZopNight schedule Compute Engine Instance?
Stopping a Compute Engine instance releases vCPU and memory billing while persistent disks ride through untouched. Local SSDs must have their data discarded to stop, and sustained-use discounts shrink as running hours drop, so the realized saving lands a few percent under what the raw 168-hour week suggests.
How the stop works
| Field | Value |
|---|---|
| Behaviour | issues an instance stop, releasing vCPU and memory billing while preserving disks; restarts on schedule |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Cores released, disks kept
The scheduled stop powers the instance down and ends its vCPU and memory charges; every persistent disk stays attached, intact and billing at its provisioned size. Start returns the same instance, same name and same internal IP inside its VPC, with the boot disk exactly as it was left.
Local SSDs are the disqualifier
An instance with local SSDs cannot simply stop: the stop requires discarding local SSD contents, because the hardware is physically bound to the host being vacated. Workloads using local SSD as scratch space can accept the nightly discard; anything treating it as real storage makes the instance a poor scheduling candidate until the data moves to persistent disk.
Sustained use discounts claw back part of the win
GCP automatically discounts instances the longer they run within a month, up to a meaningful percentage for full-month usage. Scheduling cuts running hours, which also cuts the discount tier, so an instance stopped 70% of the time saves somewhat less than 70% of its former bill. The effect is a few percentage points, not a reversal, but forecasts that ignore it consistently overpromise.
Committed use makes the schedule pointless
Instances covered by committed use discounts bill the commitment regardless of state. A scheduled stop on covered vCPUs saves nothing; the commitment invoices on. Check coverage before scheduling, and aim schedules at the on-demand remainder of the fleet where every stopped hour is a real saving.
Addresses on the restart path
An ephemeral external IP is released at stop and replaced at start, breaking any allowlist or DNS record that memorized it. Reserving a static address fixes the churn, and a reserved address on a stopped instance bills a small hourly rate, one more line in the honest overnight residual alongside the disks.
Attached GPUs stop billing with the instance, which makes accelerator-carrying machines the highest-yield candidates in most projects. They are also the ones where restart capacity deserves a moment of thought.