Maintenance window
Applies to: 
Azure SQL Database
Azure SQL Managed Instance
The maintenance window feature allows you to configure maintenance schedule for Azure SQL Database and Azure SQL Managed Instance resources making impactful maintenance events predictable and less disruptive for your workload.
Note
The maintenance window feature only protects from planned impact from upgrades or scheduled maintenance. It does not protect from all failover causes; exceptions that may cause short connection interruptions outside of a maintenance window include hardware failures, cluster load balancing, and database reconfigurations due to events like a change in database Service Level Objective.
Advance notifications (Preview) are available for databases configured to use a non-default maintenance window and managed instances with any configuration (including the default one). Advance notifications enable customers to configure notifications to be sent up to 24 hours in advance of any planned event.
Overview
Azure periodically performs planned maintenance of SQL Database and SQL managed instance resources. During Azure SQL maintenance event, databases are fully available but can be subject to short reconfigurations within respective availability SLAs for SQL Database and SQL managed instance.
Maintenance window is intended for production workloads that are not resilient to database or instance reconfigurations and cannot absorb short connection interruptions caused by planned maintenance events. By choosing a maintenance window you prefer, you can minimize the impact of planned maintenance as it will be occurring outside of your peak business hours. Resilient workloads and non-production workloads may rely on Azure SQL's default maintenance policy.
The maintenance window is free of charge and can be configured on creation or for existing Azure SQL resources. It can be configured using the Azure portal, PowerShell, CLI, or Azure API.
Important
Configuring maintenance window is a long running asynchronous operation, similar to changing the service tier of the Azure SQL resource. The resource is available during the operation, except a short reconfiguration that happens at the end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration you should perform the operation outside of the peak hours.
Gain more predictability with maintenance window
By default, Azure SQL maintenance policy blocks most impactful updates during the period 8AM to 5PM local time every day to avoid any disruptions during typical peak business hours. Local time is determined by the location of Azure region that hosts the resource and may observe daylight saving time in accordance with local time zone definition.
You can further adjust the maintenance updates to a time suitable to your Azure SQL resources by choosing from two additional maintenance window slots:
- Weekday window: 10:00 PM to 6:00 AM local time, Monday - Thursday
- Weekend window: 10:00 PM to 6:00 AM local time, Friday - Sunday
Maintenance window days listed indicate the starting day of each eight-hour maintenance window. For example, "10:00 PM to 6:00 AM local time, Monday – Thursday" means that the maintenance windows start at 10:00 PM local time on each day (Monday through Thursday) and complete at 6:00 AM local time the following day (Tuesday through Friday).
Once the maintenance window selection is made and service configuration completed, planned maintenance will occur only during the window of your choice. While maintenance events typically complete within a single window, some of them may span two or more adjacent windows.
Important
In very rare circumstances where any postponement of action could cause serious impact, like applying critical security patch, configured maintenance window may be temporarily overriden.
Advance notifications
Maintenance notifications can be configured to alert you of upcoming planned maintenance events for your Azure SQL Database and Azure SQL Managed Instance. The alerts arrive 24 hours in advance, before maintenance window opens, and at the end of maintenance window. For more information, see Advance Notifications.
Feature availability
Supported subscription types
Configuring and using maintenance window is available for the following offer types: Pay-As-You-Go, Cloud Solution Provider (CSP), Microsoft Enterprise Agreement, or Microsoft Customer Agreement.
Offers restricted to dev/test usage only are not eligible (like Pay-As-You-Go Dev/Test or Enterprise Dev/Test as examples).
Note
An Azure offer is the type of the Azure subscription you have. For example, a subscription with pay-as-you-go rates, Azure in Open, and Visual Studio Enterprise are all Azure offers. Each offer or plan has different terms and benefits. Your offer or plan is shown on the subscription's Overview. For more information on switching your subscription to a different offer, see Change your Azure subscription to a different offer.
Supported service level objectives
Choosing a maintenance window other than the default is available on all SLOs except for:
- Instance pools
- Legacy Gen4 vCore
- Basic, S0 and S1
- DC, Fsv2, M-series
- Hyperscale service tier premium-series hardware (preview)
Azure region support
Choosing a maintenance window other than the default is currently available in the following regions:
| Azure Region | SQL Managed Instance | SQL Database | SQL Database in an Azure Availability Zone |
|---|---|---|---|
| Australia Central 1 | Yes | ||
| Australia Central 2 | Yes | ||
| Australia East | Yes | Yes | Yes |
| Australia Southeast | Yes | Yes | |
| Brazil South | Yes | Yes | |
| Brazil Southeast | Yes | Yes | |
| Canada Central | Yes | Yes | Yes |
| Canada East | Yes | Yes | |
| Central India | Yes | Yes | |
| Central US | Yes | Yes | Yes |
| China East 2 | Yes | Yes | |
| China North 2 | Yes | Yes | |
| East US | Yes | Yes | Yes |
| East US 2 | Yes | Yes | Yes |
| East Asia | Yes | Yes | |
| France Central | Yes | Yes | |
| France South | Yes | Yes | |
| Germany West Central | Yes | Yes | |
| Germany North | Yes | ||
| Japan East | Yes | Yes | Yes |
| Japan West | Yes | Yes | |
| Korea Central | Yes | ||
| Korea South | Yes | ||
| North Central US | Yes | Yes | |
| North Europe | Yes | Yes | Yes |
| Norway East | Yes | ||
| Norway West | Yes | ||
| South Africa North | Yes | ||
| South Africa West | Yes | ||
| South Central US | Yes | Yes | Yes |
| South India | Yes | Yes | |
| Southeast Asia | Yes | Yes | Yes |
| Switzerland North | Yes | Yes | |
| Switzerland West | Yes | ||
| UAE Central | Yes | ||
| UAE North | Yes | Yes | |
| UK South | Yes | Yes | Yes |
| UK West | Yes | Yes | |
| US Gov Arizona | Yes | ||
| US Gov Texas | Yes | Yes | |
| US Gov Virginia | Yes | Yes | |
| West Central US | Yes | Yes | |
| West Europe | Yes | Yes | Yes |
| West India | Yes | ||
| West US | Yes | Yes | |
| West US 2 | Yes | Yes | Yes |
| West US 3 | Yes |
Gateway maintenance
To get the maximum benefit from maintenance windows, make sure your client applications are using the redirect connection policy. Redirect is the recommended connection policy, where clients establish connections directly to the node hosting the database, leading to reduced latency and improved throughput.
In Azure SQL Database, any connections using the proxy connection policy could be affected by both the chosen maintenance window and a gateway node maintenance window. However, client connections using the recommended redirect connection policy are unaffected by a gateway node maintenance reconfiguration.
In Azure SQL Managed Instance, the gateway nodes are hosted within the virtual cluster and have the same maintenance window as the managed instance, but using the redirect connection policy is still recommended to minimize number of disruptions during the maintenance event.
For more on the client connection policy in Azure SQL Database, see Azure SQL Database Connection policy.
For more on the client connection policy in Azure SQL Managed Instance, see Azure SQL Managed Instance connection types.
Considerations for Azure SQL Managed Instance
Azure SQL Managed Instance consists of service components hosted on a dedicated set of isolated virtual machines that run inside the customer's virtual network subnet. These virtual machines form virtual cluster(s) that can host multiple managed instances. Maintenance window configured on instances of one subnet can influence the number of virtual clusters within the subnet, distribution of instances among virtual clusters, and virtual cluster management operations. This may require a consideration of few effects.
Maintenance window configuration is a long running operation
All instances hosted in a virtual cluster share the maintenance window. By default, all managed instances are hosted in the virtual cluster with the default maintenance window. Specifying another maintenance window for managed instance during its creation or afterwards means that it must be placed in virtual cluster with corresponding maintenance window. If there is no such virtual cluster in the subnet, a new one must be created first to accommodate the instance. Accommodating additional instance in the existing virtual cluster may require cluster resize. Both operations contribute to the duration of configuring maintenance window for a managed instance. Expected duration of configuring maintenance window on managed instance can be calculated using estimated duration of instance management operations.
Important
A short reconfiguration happens at the end of the operation of configuring maintenance window and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration, initiate the operation outside of the peak hours.
IP address space requirements
Each new virtual cluster in subnet requires additional IP addresses according to the virtual cluster IP address allocation. Changing maintenance window for existing managed instance also requires temporary additional IP capacity as in scaling vCores scenario for corresponding service tier.
IP address change
Configuring and changing maintenance window causes change of the IP address of the instance, within the IP address range of the subnet.
Important
Make sure that NSG and firewall rules won't block data traffic after IP address change.
Serialization of virtual cluster management operations
Operations affecting the virtual cluster, like service upgrades and virtual cluster resize (adding new or removing unneeded compute nodes) are serialized. In other words, a new virtual cluster management operation cannot start until the previous one is completed. In case that maintenance window closes before the ongoing service upgrade or maintenance operation is completed, any other virtual cluster management operations submitted in the meantime will be put on hold until next maintenance window opens and service upgrade or maintenance operation completes. It is not common for a maintenance operation to take longer than a single window per virtual cluster, but it can happen in case of very complex maintenance operations.
The serialization of virtual cluster management operations is general behavior that applies to the default maintenance policy as well. With a maintenance window schedule configured, the period between two adjacent windows can be few days long. Submitted operations can also be on hold for few days if the maintenance operation spans two windows. That is very rare case, but creation of new instances or resize of the existing instances (if additional compute nodes are needed) may be blocked during this period.
Retrieving list of maintenance events
Azure Resource Graph is an Azure service designed to extend Azure Resource Management. The Azure Resource Graph Explorer provides efficient and performant resource exploration with the ability to query at scale across a given set of subscriptions so that you can effectively govern your environment.
You can use the Azure Resource Graph Explorer to query for maintenance events. For an introduction on how to run these queries, see Quickstart: Run your first Resource Graph query using Azure Resource Graph Explorer.
To check for the maintenance events for all SQL databases in your subscription, use the following sample query in Azure Resource Graph Explorer:
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
To check for the maintenance events for all managed instances in your subscription, use the following sample query in Azure Resource Graph Explorer:
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
For the full reference of the sample queries and how to use them across tools like PowerShell or Azure CLI, visit Azure Resource Graph sample queries for Azure Service Health.
Next steps
Learn more
Feedback
Submit and view feedback for