Cloud SQL instances averaging under 5 connections that sit idle off-hours
What does ZopNight detect here?
A running Cloud SQL instance bills for its vCPUs and memory whether or not anyone connects. ZopNight flags `RUNNABLE` instances averaging fewer than 5 connections over 30 days, and prices an off-hours stop and start schedule from the measured share of the week the database is idle.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-103 |
| Category | schedule |
| Severity | medium |
| Metric | database/network/connections |
| Threshold | average connections under 5 |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | cloudsql.instances.list · cloudsql.instances.get · monitoring.timeSeries.list |
Where it applies
A running database bills even with no clients
Cloud SQL charges for the instance’s compute while it is up. The
start and stop guide
describes the activation policy: ALWAYS keeps the instance running, and if you are not using
it you can set NEVER “to avoid instance charges”. Storage, backups and any reserved IP keep
billing while it is stopped, because the instance still exists.
Development, demo and internal-tool databases often see a handful of connections during working hours and none overnight.
Measuring connections yourself
gcloud sql instances list --filter="state=RUNNABLE" \ --format="table(name,databaseVersion,region)"Chart cloudsql.googleapis.com/database/network/connections for a candidate over 30 days.
Google documents that metric for MySQL and SQL Server only, which matters below.
Low connections plus a measured idle window
The instance must be RUNNABLE, its average connection count over 30 days must be under 5, and
ZopNight’s usage heatmap, which includes Cloud SQL CPU, must show a measurable off-hours idle
window. The lever is a recurring stop and start schedule; ZopNight does not change the database
tier.
Databases this rule skips
With no connection series, there is no finding, so instances whose engine does not report that metric are not scored here. The rule also stays silent when the instance has no priced cost or when the heatmap shows no idle share. Read replicas cannot be stopped, per Google, so a schedule is not an option for them.
Idle share of compute cost
saving = monthly instance cost x measured off-hours idle sharecost after fix = monthly instance cost - savingOnly compute stops during off-hours. Deleting the instance is the only way to remove storage, backup and IP charges.
Scheduling the stop and start
- Confirm no batch job, replica or reporting tool connects during the proposed off-hours.
- Apply the schedule from the recommendation, which stops and starts the instance automatically.
- To stop by hand, run
gcloud sql instances patch INSTANCE_NAME --activation-policy=NEVER, and useALWAYSto start it again. - Delete the instance only if the data is no longer needed, after taking a final backup.