Cloud SQL tiers oversized for their measured CPU
What does ZopNight detect here?
Cloud SQL instances averaging under 10% CPU across 30 days are carrying a larger tier than the workload needs. ZopNight picks the next-smaller tier from the machine catalog, prices the move from live SKU rates, and leaves the resize itself to your DBA; it never mutates customer databases.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-113 |
| Category | rightsizing |
| Severity | high |
| Metric | none — pure configuration read |
| Source | cloudsql_rightsizing.go |
Where it applies
A 10% average is the trigger
Databases get sized for launch-day fears, then run for years at a fraction of that. The
rule reads CloudSQLCPUUtilization over 30 days and fires when the average sits below
10%. Such an instance barely touches its CPU while the tier bills for every provisioned
core. The metric arrives through monitoring.timeSeries.list
(roles/monitoring.viewer); a memory-pressure veto exists so an instance that is
CPU-quiet but memory-bound is not downsized out of its RAM.
The target must exist in the catalog
“Use a smaller tier” is not actionable advice, so the rule walks the Cloud SQL machine ladder and names a concrete next-smaller tier, using the full-series peak as a conservative stand-in for p95: a windowed slice is never allowed to hide an older spike and pick a too-aggressive tier. The saving is the real rate difference between the two tiers, 1 − target/current, applied to the instance’s monthly cost. Rate deltas outside a 5%–85% sanity band are discarded as probable catalog mismatches rather than shipped.
Why ZopNight will not resize it for you
Database tier changes restart the instance and sit squarely in DBA territory, so this recommendation is advisory by policy: ZopNight never mutates customer database tiers on any cloud. The remediation is guidance for the team that owns the change window. Pick a current-generation Enterprise tier or a db-custom shape sized to observed CPU and memory, and avoid the legacy shared-core tiers.
Confirm the tier and the CPU curve
gcloud sql instances describe my-instance \ --format="value(settings.tier,settings.availabilityType)"Then open Cloud Monitoring and check both average and p95 CPU for the same 30-day window before scheduling the resize.
Cases the rule refuses to price
No recommendation is produced for stopped instances, when the CPU metric is absent, when memory utilization is recorded at 60% or higher, when cost is unknown, when no provably smaller tier exists (already-smallest tiers, db-custom shapes, and the shared-core floor all end the walk), or when either SKU rate is missing, inverted, or out of band. The old fallback that guessed 50% of cost is gone; every figure shown is backed by a real rate pair.