Cloud SQL instances averaging under 5 connections that could park off-hours
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-103 |
| Category | schedule |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | idle_cloudsql.go |
Where it applies
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
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.