Does setting a maintenance window guarantee zero downtime during that window?

No. The window controls when maintenance can start, not whether it causes a restart. Most patches apply with a brief failover for HA instances (seconds of interruption) or a full restart for non-HA instances. The window just bounds the timing risk to a period you chose, it doesn't eliminate the interruption itself.

Can I block maintenance indefinitely by chaining deny periods?

No, each denyMaintenancePeriods entry is capped at 90 days, and Cloud SQL enforces mandatory maintenance at least once every 12 months regardless of deny periods you've set — an instance can't opt out of security patching forever, only defer it.

What's the difference between backupRetentionSettings.retainedBackups and transactionLogRetentionDays?

retainedBackups controls how many discrete backup snapshots are kept (up to 365). transactionLogRetentionDays controls the binary log (MySQL) or WAL (PostgreSQL) window available for point-in-time recovery, and is capped independently at 7 days — you can keep 30 backups but still only roll back to any second within the last 7 days.

GCP Cloud SQL Maintenance Window Builder

StorageGCP

Build Cloud SQL maintenance window configurations with preferred schedules and deny periods.

Cloud SQL Maintenance Configuration

Build Cloud SQL maintenance window configurations with preferred schedules, deny periods, and backup settings.

Required Fields

instanceprojectsettings.maintenanceWindow.daysettings.maintenanceWindow.hoursettings.maintenanceWindow.updateTrack

{
  "instance": "prod-db-primary",
  "project": "my-project",
  "settings": {
    "maintenanceWindow": {
      "day": 7,
      "hour": 4,
      "updateTrack": "stable"
    },
    "denyMaintenancePeriods": [
      {
        "startDate": "2026-11-25",
        "endDate": "2026-12-02",
        "time": "00:00:00"
      },
      {
        "startDate": "2026-12-20",
        "endDate": "2027-01-05",
        "time": "00:00:00"
      }
    ],
    "insightsConfig": {
      "queryInsightsEnabled": true,
      "queryStringLength": 4096,
      "recordApplicationTags": true,
      "recordClientAddress": true
    },
    "backupConfiguration": {
      "enabled": true,
      "startTime": "03:00",
      "location": "us",
      "pointInTimeRecoveryEnabled": true,
      "transactionLogRetentionDays": 7,
      "backupRetentionSettings": {
        "retainedBackups": 30,
        "retentionUnit": "COUNT"
      }
    },
    "userLabels": {
      "environment": "production",
      "maintenance-policy": "conservative"
    }
  }
}

Generated Output

Output will appear here...

About This Tool

Build a Cloud SQL maintenance window and deny-period configuration that controls when Google is allowed to apply instance updates, kernel patches, and minor version upgrades. The day field is ISO 8601 (1=Monday through 7=Sunday) and hour is a 0-23 UTC value, not your instance's local timezone, which is the single most common misconfiguration teams hit when they schedule a '2am maintenance' window that actually fires during business hours. denyMaintenancePeriods let you block maintenance entirely for date ranges like a holiday freeze, up to 90 days per period.

Real-World Scenario

An SRE sets what they believe is a Sunday 2am maintenance window for a US Eastern Cloud SQL instance, using hour: 2, and three weeks later a scheduled patch restarts the primary at 2am UTC, which is 9pm Saturday Eastern, right in the middle of a weekend batch job that assumed the database wouldn't restart until after 2am local. They rebuild the config with the builder, setting hour: 6 to correctly land the window at 2am Eastern (standard time) and add a denyMaintenancePeriods block around the batch job's known runtime windows so future overlaps are blocked outright instead of relying on getting the UTC math right by hand.

When to Use This Tool

•Pinning updateTrack to stable instead of the default canary/week5 rollout so patches land on this production instance a week or more after Google first ships them to canary customers.
•Adding a denyMaintenancePeriods block covering Black Friday through Cyber Monday so no maintenance-triggered restart can happen during peak checkout traffic.
•Converting a team's assumed '2am Sunday' maintenance window from local Pacific time into the UTC hour Cloud SQL actually expects, after a restart hit during business hours in daylight saving transition.
•Enabling insightsConfig query insights with recordApplicationTags so a slow-query investigation can be filtered by the calling service instead of scanning raw SQL text.

Pro Tips

TIP

hour is UTC, always — a team in US Eastern time wanting a true 2am local maintenance window needs hour: 6 (EST) or hour: 7 (EDT), and this shifts twice a year with DST if you don't account for it.

TIP

updateTrack: "week5" delays rollout roughly five weeks after canary but isn't a guarantee of avoiding a bad patch, it's a documented best-effort delay tier, not a hold-for-manual-approval gate.

TIP

pointInTimeRecoveryEnabled requires binary logging (MySQL) or WAL archiving (PostgreSQL) to already be on; enabling PITR on an instance that had it off starts the recovery window from that moment forward, it doesn't retroactively cover data written before you flipped the flag.

How It Works Under the Hood

The builder checks that instance, project, and the three maintenanceWindow fields (day, hour, updateTrack) resolve before treating the config as a valid Cloud SQL Admin API patch body — those are the fields the API actually rejects a request over if they're missing or out of range (day must be 1-7, hour must be 0-23).

Frequently Asked Questions

Does setting a maintenance window guarantee zero downtime during that window?: No. The window controls when maintenance can start, not whether it causes a restart. Most patches apply with a brief failover for HA instances (seconds of interruption) or a full restart for non-HA instances. The window just bounds the timing risk to a period you chose, it doesn't eliminate the interruption itself.
Can I block maintenance indefinitely by chaining deny periods?: No, each denyMaintenancePeriods entry is capped at 90 days, and Cloud SQL enforces mandatory maintenance at least once every 12 months regardless of deny periods you've set — an instance can't opt out of security patching forever, only defer it.
What's the difference between backupRetentionSettings.retainedBackups and transactionLogRetentionDays?: retainedBackups controls how many discrete backup snapshots are kept (up to 365). transactionLogRetentionDays controls the binary log (MySQL) or WAL (PostgreSQL) window available for point-in-time recovery, and is capped independently at 7 days — you can keep 30 backups but still only roll back to any second within the last 7 days.

Related Learning Guides

GCS Storage Classes & Lifecycle22 min read
Memorystore for Redis Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.