# Idle GCP Cloud SQL Instance

> Cloud SQL instances averaging fewer than 5 database connections over the window are candidates for an off-hours stop/start schedule. Stopping is an activationPolicy patch to NEVER rather than a stop API call, compute charges pause, and provisioned storage, backups and IP reservations keep billing while the instance exists.

Source: https://zop.dev/integrations/gcp/recommendations/idle-gcp-cloud-sql-instance
Updated: 2026-08-19

---

## Five connections is the line

The idle test reads the `DatabaseConnections` series and asks whether the average sits
below 5. The comparison deliberately runs over the full harvested series rather than a
trimmed window: an instance that had real connections five weeks ago but went quiet last
month is *not* flagged, because hiding older activity would make an idle verdict easier,
and easier is the wrong direction for a rule that stops databases. ZopNight never mutates
database tiers on any cloud; the lever here is purely temporal.

## Stop is a policy patch, not an API

Cloud SQL has no stop endpoint. "Stopping" an instance means patching its
`activationPolicy` from `ALWAYS` to `NEVER`, which is why the permission involved is
`cloudsql.instances.update` (with `cloudsql.instances.get`) inside `roles/cloudsql.editor`
rather than anything named stop. Two practical consequences: audit logs show a
configuration change, not a lifecycle event, and tooling that watches for stop events
will not see the schedule working.

## What a parked instance still bills

Compute pauses; storage, automated backups, and any reserved IP keep billing at full
rate while the instance exists. The recommendation's saving is therefore the compute
share only: the instance's monthly cost times the idle fraction measured from its usage
heatmap. If a database is idle every hour of the week, deletion (after export) is the
honest endgame; the schedule is for the dev database that works business hours.

## Watch the connection series

```bash
gcloud sql instances describe my-instance \
  --format="value(settings.activationPolicy,state)"
```

Then confirm the flat connection count in Cloud Monitoring for the same 30-day span the
rule used. The metric is read via `monitoring.timeSeries.list` in
`roles/monitoring.viewer`.

## Schedule data or silence

Four things must all exist before a recommendation appears: a runnable instance, the
connections metric with a below-5 average, a known positive cost, and heatmap-derived
schedule data with a positive measured idle fraction. Missing any of them produces
nothing, and the rule has no assumed idle percentage and no advisory fallback.