AzureFeeds

Azure Database for PostgreSQL periodically applies updates—such as minor version patches and security fixes—during scheduled maintenance windows to keep your databases secure and stable. For mission-critical workloads, it’s best practice to validate those changes in development or test environments first, catching issues early and minimizing risk before affecting production.

Flexible Server’s maintenance scheduling options enable this phased rollout by giving you both advance notice and control: you get early visibility into updates, can choose low-impact windows for production, and enjoy peace of mind knowing patches have been vetted in non-prod first. This article shows how to leverage System-Managed Windows (SMW) and Custom Maintenance Windows (CMW)** to patch Dev/UAT servers first and defer production updates by a week.

System-Managed vs. Custom Maintenance Windows

Azure offers two types of maintenance scheduling for PostgreSQL flexible server:

• System-Managed Window (SMW): The default setting where Azure automatically selects a one-hour maintenance window between 11:00 PM and 7:00 AM in your server’s region. You do not choose the day or time – the system schedules it for you, once every 30 days (outside of critical hotfixes). This option is ideal for non-production servers (Dev, QA, UAT) because it ensures they receive updates as early as possible. Early patching on dev/test allows you to catch any issues in a safe environment before they affect end-users.


• Custom Maintenance Window (CMW): An optional setting where you define the maintenance timing by specifying the day of week and start time for a one-hour window. Production servers can use a custom window so that you can control when maintenance happens (e.g., during low traffic period). Importantly, Azure schedules custom-window maintenance 7 days after the system-managed schedule in the same region. In practice, this means if Dev/Test servers (on SMW) get patched this week, your Production server (on CMW) will be patched about a week later during the custom slot you chose.


• For more on how these schedules work, refer System-Managed vs. Custom Maintenance Windows.

By combining these settings, you create a staggered rollout: Dev and QA servers get updated first (using SMW), and Production follows one week later (using CMW). Azure also sends maintenance notifications 5 days in advance of any scheduled update. Together, the 5-day notice plus the 7-day scheduling gap give production teams over 10 days of lead time to observe the update’s impact in lower environments before it reaches Prod.

💡 Tip: Use Azure Service Health alerts to stay on top of maintenance notifications. You can configure alerts (email, SMS, etc.) so you know when an update is scheduled or completed.

Configuring a Custom Maintenance Window (Prod) vs. System-Managed (Dev)

Setting up a staggered maintenance strategy in Azure is straightforward. You will leave Dev/Test servers on the default (system-managed) schedule and configure a custom window for Production. Below are steps to do this using both the Azure Portal and Azure CLI.

Using the Azure Portal

1. Open the flexible server resource: In the Azure Portal, navigate to your PostgreSQL Flexible Server (e.g., your production server). In the left-hand Settings menu, click Maintenance. This opens the maintenance schedule blade (as shown in the screenshot below).


2. Select schedule type: By default, System-managed schedule is selected. For a production server, choose Custom schedule. This will display dropdown fields for Day of the week and Start time (UTC).

Image Illustration: Azure Database for PostgreSQL Flexible Server maintenance settings in Azure Portal. Selecting “Custom schedule” allows you to specify the day and UTC start time for a one-hour maintenance window.

1. Choose day and time: Pick a day of week and start time for your production maintenance window. For example, you might choose Sunday at 00:00 UTC. Remember that the maintenance window lasts one hour from the start time. (Outside of critical hotfixes, Azure will apply updates no more than once every 30 days.)


2. Save changes: Click Save. Azure will update the maintenance schedule for this server. Going forward, this server will always use your specified weekly window for maintenance. (Note: if a maintenance event was already scheduled in the current cycle, changing the window now will not affect that pending event – the new setting takes effect from the next cycle.)

For your Dev/Test servers, you can simply leave the System-managed schedule selected. The system-managed option does not require further configuration – Azure will pick a random one-hour slot during off-peak hours. If you had previously set a custom window on a non-prod server and want to revert it to the default behavior, you can switch back to system-managed by selecting that option in the Portal and saving, or via CLI.

Note: Currently, Azure schedules custom maintenance ~7 days after system-managed maintenance in the same region. This timing may change in the future, so consider this a current workaround.

Using Azure CLI

You can also configure maintenance windows using the Azure CLI, which is handy for scripting or applying settings to many servers at once. Use the az postgres flexible-server update command with the –maintenance-window parameter:

• System-managed (default): To ensure a server uses the system-chosen schedule, set –maintenance-window Disabled. For example, for a dev server:

az postgres flexible-server update
–resource-group MyResourceGroup
–name my-dev-server
–maintenance-window Disabled

 

• Custom schedule: To set a custom window, specify :: in UTC (the time is optional; if omitted, it defaults to 00:00). For example, to schedule maintenance for Wednesdays at 14:29 UTC on a production server, run:

az postgres flexible-server update
–resource-group MyResourceGroup
–name my-prod-server
–maintenance-window Wed:14:29

This configures a one-hour window starting at 14:29 UTC every Wednesday for the given server. Be sure to adjust the day/time to suit your region’s off-hours. All servers with a custom window will receive updates ~7 days after the region’s system-managed patch week.

Summary of Benefits for Mission-Critical Workloads

Staggering maintenance updates (Dev first, Prod later) offer key benefits for mission-critical Azure PostgreSQL deployments:

• Early Issue Detection: Catch and address issues early in Dev/UAT environments before reaching production.


• Extended Lead Time: Get 10-12 days advance notice to coordinate with stakeholders and plan for any downtime.


• Controlled Scheduling: Choose low-impact, off-peak maintenance windows for your production environment.


• Reduced Risk: Improve overall reliability and stability by validating updates first in non-prod servers.

Conclusion: Staggering maintenance updates for Dev and Prod in Azure PostgreSQL Flexible Server is a simple yet effective strategy to safeguard your production environment. By leveraging built-in maintenance windows, you can achieve a phased rollout of updates – gaining confidence from early testing, and delivering a more robust, resilient service to your end users.

** Note: We’re reviewing Custom Maintenance Window support for Burstable SKUs and may update this behavior in a future release. Any changes will be announced and documented in advance.