Cloud SQL instances with no maintenance window, leaving Google to pick when updates land

What a Cloud SQL maintenance update costs in downtime

Cloud SQL schedules a maintenance update typically once every few months. The maintenance overview puts each one at roughly 5 to 10 minutes per instance, during which a Cloud SQL Enterprise edition instance loses connectivity for less than 60 seconds on average. Heavy write activity or a very large dataset can stretch that. Enterprise Plus instances get near-zero downtime maintenance, typically under a second.

If you never set a window, Cloud SQL still avoids business hours in a coarse way: the same page lists default windows of 10 PM to 6 AM Monday to Friday and Friday 10 PM to Monday 6 AM on weekends, in the instance’s time zone. That is an eight-hour weeknight band you did not choose. For a database behind a nightly batch job, an overnight ETL, or users in another time zone, “somewhere overnight” can be the busiest hour of the day.

Seeing which instances have a window today

List every instance with its configured maintenance day and hour:

gcloud sql instances list \
  --format="table(name, databaseVersion, settings.maintenanceWindow.day, settings.maintenanceWindow.hour)"

For any instance where the day column is empty, open it in the console and look at the Maintenance section; “Any window” means no specific slot has been chosen. Read replicas can carry their own window, so check them as well as primaries.

The one setting behind this finding

ZopNight reads each instance’s settings through Cloud Asset Inventory and records whether they contain a maintenance window block. The rule fires when there is no such block. An instance set to “Any window” can still return a block, in which case it counts as configured and is not flagged. No metric, lookback period, engine, edition or naming convention is involved, and the check repeats on every evaluation, so the finding clears on its own once a window is saved.

When the rule stays quiet

ZopNight only judges instances whose full settings it has already read. An instance that appears in the inventory before its details have been collected is skipped rather than reported, so a partial scan cannot produce a burst of findings. Once any window exists the rule is satisfied: it does not second-guess whether the hour you picked is actually quiet for your workload.

No saving here, just control over timing

This is a governance check and carries no dollar figure. What it buys is predictability: an outage of up to a minute, repeated every few months, happens at an hour your team chose and announced, instead of whenever the default band allows. That is the difference between a scheduled blip and a pager alert.

Pinning maintenance to a quiet slot

1. Find the lowest-traffic hour for the instance and convert it to UTC, since gcloud takes the day and hour in UTC.

2. Save the window and choose a maintenance timing channel:

   gcloud sql instances patch INSTANCE_NAME \
     --maintenance-window-day=SUN \
     --maintenance-window-hour=3 \
     --maintenance-release-channel=production

3. Use the timing channels to stage risk. Per Google’s instructions, preview lands 7 to 14 days after the notification, production 15 to 21 days, and week5 35 to 42 days. Put staging on an earlier channel than production so problems show up there first.

4. Add a deny maintenance period, up to 90 days long, around peak seasons.

5. Opt in to maintenance notifications so the owning team hears about each rollout in advance.