Scheduling Cloud SQL Instance

A policy, not a power button

Stopping a Cloud SQL instance means writing activationPolicy: NEVER to its settings and letting the platform wind the instance down; the morning start writes ALWAYS. The write returns immediately but the actual state change is a long-running operation that completes minutes later, so the cron firing is the beginning of the stop, not the moment of it.

One operation at a time, and nights are busy

Each instance processes a single admin operation at a time, and the small hours are when automated backups and maintenance already run. A stop that lands mid-backup waits or fails behind it. Place the stop cron clear of the instance’s backup window: before it, with the backup then running against a stopped instance’s policy, or comfortably after it finishes. The first week of overlapping windows produces exactly the kind of intermittent failure that erodes trust in a schedule.

What a stopped instance still rents

Disk billing continues at the provisioned size, backups continue to occupy paid storage, and a static public IPv4 attached to a stopped instance keeps charging by the hour. The saving is the vCPU-and-memory line. On a db-custom instance with a modest disk that is most of the bill, but on a small instance with a 500 GB disk the split deserves a look first.

Replicas complicate the picture

Read replicas have their own compute and their own policies; stopping a primary does not stop them. A replica left running against a stopped primary saves half the money and earns a broken replication stream. Schedule the topology as a unit, taking replicas down first and the primary after, then bringing the primary up first and the replicas after.

Morning behavior

Once ALWAYS lands and the operation completes, the instance boots and applications reconnect through their pools. Budget several minutes between the start cron and the first dependent job, because the asynchronous operation offers no exact completion moment to schedule against.