# Scheduling Cloud SQL Instance

> Cloud SQL has no stop verb. The schedule sets activationPolicy to NEVER, an asynchronous long-running operation, and restores ALWAYS at start. Cloud SQL runs 1 admin operation at a time, so stops can queue behind backups, and a stopped instance still bills storage plus any static IPv4 it holds.

Source: https://zop.dev/integrations/gcp/cloudsql/schedule
Updated: 2026-08-19

---

## 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.