You can manage how Atlas rolls out maintenance for your projects by configuring:
Protected Hours: Business-critical hours during which standard updates can't occur.
Maintenance Windows: The time of day when Atlas starts weekly maintenance that requires replica set elections for clusters in a project.
Maintenance Waves: The order in which projects in your organization receive maintenance. Maintenance waves are labelled sequentially, from Wave 1 to Last Wave.
You can visualize how Atlas rolls out maintenance to your projects given your maintenance windows, protected hours, and maintenance waves using the Projected Maintenance Calendar tool.
Important
Maintenance windows, protected hours, and maintenance waves are configured per project and they apply only to Dedicated clusters (M10 and above). For Free clusters and Flex clusters, Atlas manages their maintenance windows automatically and you can't configure them manually.
We recommend that you set maintenance windows, protected hours, and maintenance waves, though all are optional. Atlas performs maintenance automatically in a rolling manner to preserve continuous availability for resilient applications. To confirm that your application is resilient to replica set elections, test failover in Atlas.
To learn more, see:
Maintenance Management Considerations
Protected hours: In addition to configuring a maintenance window, you can set daily protected hours, which is a timeframe during which Atlas avoids performing standard updates. The length of your protected hours window can't exceed 18 hours.
While Atlas can perform standard updates that don't involve a cluster restart or impact workload performance outside of your configured maintenance window, Atlas always respects protected hours.
Urgent maintenance activities: Atlas may perform urgent maintenance activities (such as security patches for zero-day vulnerabilities) as soon as necessary without regard to configured maintenance windows, protected hours, or maintenance waves.
Ongoing maintenance operations: Once you schedule a maintenance window for your cluster, you cannot change it until any ongoing maintenance operations have completed.
MongoDB database upgrades: If maintenance includes a MongoDB minor or patch version upgrade, Atlas displays the current and target versions in the console. If Atlas upgrades the MongoDB maintenance version on one of your clusters during the next maintenance window, the cluster's card displays the target MongoDB maintenance version.
Maintenance requires replica set elections: Atlas performs maintenance the same way as the maintenance procedure described in the MongoDB Manual. This procedure requires at least one replica set election during the maintenance window per replica set. To confirm that your application is resilient to replica set elections, test failover in Atlas.
Maintenance starts as close to the start of the window as possible: Maintenance always begins as close to the scheduled time as possible, but in-progress cluster updates or unexpected system issues could delay the start time.
Potential for brief performance degradation during maintenance: If you have low Disk IOPS, your cluster could experience a brief performance degradation during maintenance while MongoDB repopulates the WiredTiger storage engine. To learn more, see Journaling and the WiredTiger Storage Engine.
Default Maintenance Waves: Atlas automatically assigns maintenance waves to projects without explicit wave assignments using the following rules:
Atlas assigns projects without a configured maintenance window to Wave 1.
Atlas assigns projects with a configured maintenance window to Wave 2.
You can manually change these wave assignments at anytime. To learn more, see Configure Maintenance Management Settings.
Maintenance waves evaluation: Atlas evaluates the configured maintenance waves at the time a maintenance event first goes out. If you make changes to the maintenance waves between when a maintenance event starts and is completed across all waves, Atlas begins using the new maintenance waves at the start of the next maintenance event.
Time between maintenance: When you have maintenance waves configured, there is at least a 48-hour gap between when Atlas rolls out maintenance to one wave and the following wave. A maintenance must complete for all projects assigned to a given wave before Atlas proceeds to the next wave, starting with Wave 1.
Scheduled Maintenance Operation Types
The Scheduled Maintenance Operations modal may display one or more of the following maintenance types:
MongoDB Required Maintenance: Critical maintenance operations required for cluster health and stability.
MongoDB Version Update: Upgrades to MongoDB minor versions, patch versions, or maintenance releases.
OS Policy Version Update: Updates to the underlying operating system policies and security patches.
Other Maintenance Operation: Additional maintenance activities required for cluster management.
Track Maintenance Completion
You'll see a Maintenance window completed event in your Project Activity Feed when maintenance operations finish.
Auto-Defer for Future Maintenance Windows
You can enable the Automatically defer maintenance for one week option to have Atlas automatically defer future scheduled maintenance by one week each time. This means maintenance effectively runs every two weeks instead of weekly, since the first week is automatically deferred each time. If needed, you can still manually defer maintenance an additional time.
Important
If you have maintenance waves configured for projects in an organization, you can't configure auto-deferring maintenance for projects in that organization.
If you enable the Automatically defer maintenance for one week option, Atlas configures automatic deferral for future maintenance windows. To defer currently scheduled maintenance, use the Defer 1 Week option as described in the Defer Maintenance section.
Auto-defer allows you to consolidate maintenance operations into a single maintenance window and reduce the total number of maintenance events. If you want to test maintenance in lower environments to validate updates before they reach production, use Maintenance Waves instead of using auto-defer.
To enable auto-defer, see Configure Maintenance Management Settings.
Using Maintenance Waves with Environment Separation
Many code development settings separate their workflow into different environments, most commonly:
Development (Dev): Where developers initially write and test new code.
Quality Assurance (QA): Where testers review the code for bugs, performance, and reliability in environments that mimic real world workloads.
Production (Prod): Where end users access and interact with the code.
Maintenance waves are useful for environment separated workflows as they allow you to monitor how cluster maintenance impacts internal environments before rolls out to user-facing environments.
To use maintenance waves for projects across these or similar environments, we recommend setting up each environment with the same maintenance waves and protected hours. Then, assign each environment to a maintenance wave as follows:
Dev to Wave 1
QA to Wave 2
Prod to Last Wave
This guarantees an at least seven day period between maintenance events being rolled out to each environment. You can also defer maintenance by an additional seven days for projects assigned to Last Wave.
Projected Maintenance Calendar Tool
To visualize when a maintenance event will roll out to your projects, you can use the Projected Maintenance Calendar tool. This tool allows you to enter potential maintenance windows and waves and a maintenance release date. Given these settings and release date, the tool displays the date and time at which Atlas would perform maintenance on the projects in each wave.
This tool is not linked to your Atlas account. It can't read settings you have configured in Atlas or configure settings for your projects or organizations.