> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Auto-Scaling Operations and Alerts This page covers auto-scaling operations: reviewing auto-scaling activity, configuring auto-scaling alerts, enhancing auto-scaling with effective fields, and getting support for auto-scaling. ## Review Auto-Scaling Activity Feed You can [view Activity Feed](https://www.mongodb.com/docs/atlas/tutorial/activity-feed.md#std-label-view-activity-feed) to review the events for each Atlas project. When any auto-scaling event occurs, Atlas logs the event in the project Activity Feed. Atlas uses the following audit [auto-scaling events.](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#std-label-alert-conditions-autoscaling) Each auto-scaling event in the Activity Feed includes detailed information about what triggered the scaling action, including: - The specific metric that triggered the auto-scaling event (such as CPU utilization, memory usage, or disk space). - The threshold value that was exceeded. - Whether the scaling was triggered by reactive auto-scaling (in response to current resource usage) or predictive auto-scaling (in anticipation of forecasted demand). To view or download only auto-scaling events: 1. Filter the activity feed for Atlas events. In the Activity Feed, click the Filter by event(s) menu and check Atlas. 2. Search for auto-scaling events. In the search box above the list, start typing `auto-scaling`. In the right-hand side of the menu, all auto-scaling events display. Deselect any that you don't want to see. The feed list automatically updates with each change you make. ## Configure Alerts for Auto-Scaling Events **Important:** In early August 2024, Atlas replaced legacy auto-scaling notification emails with configurable [auto-scaling events](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#std-label-alert-conditions-autoscaling). By default, Atlas continues to send all alert notifications to the project owners. You can [customize your auto-scaling alert distribution](https://www.mongodb.com/docs/atlas/configure-alerts.md#std-label-configure-autoscaling-alert) to change alert recipients or a distribution method. Auto-scaling activities are a subset of [Atlas alerts](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#std-label-alert-conditions). Each time Atlas triggers any of the [auto-scaling events](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#std-label-alert-conditions-autoscaling), you receive default Atlas alerts. You can opt out of or change alert configuration for some or all auto-scaling events at a project level. **Important:** Auto-scaling alerts apply to all clusters in a project. You cannot scope alerts to specific clusters. Alert notifications identify which cluster triggered the event by cluster name and ID. To modify an alert configuration, in the Category section, select Atlas Auto Scaling and then select the Condition/Metric from the list. You can then modify roles for alert recipients, change a notification method, such as email or SMS, and add a notifier, such as Slack. To learn more, see [Configure an Auto-Scaling Alert.](https://www.mongodb.com/docs/atlas/configure-alerts.md#std-label-configure-autoscaling-alert) ## Enhance Auto-Scaling with Effective Fields in Terraform **Note:** This feature only applies to dedicated clusters in the `M10` tier and upwards, and it is not supported for Flex clusters. When auto-scaling is enabled on a cluster, Atlas automatically adjusts instance sizes and storage capacity based on workload. If you use [MongoDB & HashiCorp Terraform](https://www.mongodb.com/atlas/hashicorp-terraform) for your cluster instance sizing and storage configurations, you can specify effective fields for a subset of cluster sizing values. We recommend this approach, this way: - Spec attributes remain exactly as you defined in your Terraform configuration. - Default and auto-scaled values are available separately in effective specs (for example, `effectiveElectableSpecs`), and no resource drift occurs when Atlas auto-scales your cluster. - Your configuration stays clean and represents your intent, while effective specs show the reality of what Atlas has provisioned. Effective fields ignore only changes to fields managed by specific types of auto-scaling. The following table details the fields ignored when effective fields and specific types of auto-scaling are enabled: | Type of Auto-Scaling Enabled | Specs | Ignored Fields | Node Type | | --- | --- | --- | --- | | Compute or Storage | `electableSpecs` | `instanceSize`, `diskSizeGB`, `diskIOPS` | [Electable node](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-electable-node) | | Compute or Storage | `readOnlySpecs` | `instanceSize`, `diskSizeGB`, `diskIOPS` | [Read-only node](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-read-only-node) | | Analytics | `analyticsSpecs` | `instanceSize` | [Analytics node](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-analytics-node) | You cannot use effective fields for [search nodes.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-fts-search-node-cost-overview) ### Enable Effective Fields ### API To enable effective fields, include the following header in the API request: ```bash --header "Use-Effective-Instance-Fields: true" ``` ### Behavior of Effective Fields Overall, effective fields behaviour falls into one of three scenarios: #### Effective fields and auto-scaling are enabled ##### Spec fields store your last node configuration, while effective fields show the values after latest auto-scaling event. Click to see a code example of this scenario. **Note: We recommend enabling effective fields as a best practice.** ```json { "replicationSpecs": [ { "regionConfigs": [ { "analyticsAutoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "autoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "effectiveAnalyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "effectiveElectableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "effectiveReadOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "electableSpecs": { "instanceSize": "M20", "diskSizeGB": 50.0, "nodeCount": 3 }, "priority": 7, "providerName": "AWS", "regionName": "US_EAST_1" } ], "zoneId": "6924a70c67695449ba5625ce", "zoneName": "Zone 1" } ] } ``` #### Effective fields are enabled and auto-scaling is disabled ##### Spec fields store your last node configuration, while effective fields show the values that Atlas stores internally. Click to see a code example of this scenario. **Note: We recommend enabling effective fields as a best practice.** ```json { "replicationSpecs": [ { "regionConfigs": [ { "effectiveAnalyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "effectiveElectableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "effectiveReadOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "electableSpecs": { "instanceSize": "M30", "diskSizeGB": 100.0, "nodeCount": 3 }, "priority": 7, "providerName": "AWS", "regionName": "US_EAST_1" } ], "zoneId": "6924a70c67695449ba5625ce", "zoneName": "Zone 1" } ] } ``` #### Effective fields are disabled and auto-scaling is enabled (Not recommended) ##### Effective field values always match exactly those set in the corresponding specifications. Click to see a code example of this scenario. **Important:** If you don't enable effective fields, you must manually configure a `lifecycle.ignore_changes` block to prevent resource drift when auto-scaling occurs. **We do not recommend this approach** . To learn more, see [Auto-Scaling](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/advanced_cluster#auto_scaling) in the Terraform documentation. ```json { "replicationSpecs": [ { "regionConfigs": [ { "analyticsAutoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "autoScaling": { "compute": { "maxInstanceSize": "M30", "minInstanceSize": "M10", "enabled": true, "scaleDownEnabled": true }, "diskGB": { "enabled": true } }, "effectiveAnalyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "effectiveElectableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "effectiveReadOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "analyticsSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "electableSpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 3 }, "readOnlySpecs": { "instanceSize": "M30", "diskIOPS": 3000, "diskSizeGB": 100.0, "ebsVolumeType": "STANDARD", "nodeCount": 0 }, "priority": 7, "providerName": "AWS", "regionName": "US_EAST_1" } ], "zoneId": "6924a70c67695449ba5625ce", "zoneName": "Zone 1" } ] } ``` #### Adjust the Auto-Scaling Range with Effective Fields If you enable [effective fields](https://www.mongodb.com/docs/atlas/cluster-autoscaling-operations.md#std-label-effective-fields), Atlas validates any new auto-scaling range against the cluster's current effective instance size. Atlas rejects a request that sets a range that doesn't contain the current effective instance size. This behavior applies to [operational nodes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-operational-node) and [analytics nodes](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-analytics-node) that use auto-scaling. The request fails with a validation error in either of these cases: - The new minimum instance size is larger than the effective instance size. - The new maximum instance size is smaller than the effective instance size. If the new range still contains the current effective instance size, you can change the bounds in a single request. If the current effective instance size falls outside the new range, use the following procedure to move it into the new range before you change the bounds. If you update the instance size in the same request as the range change, Atlas doesn't apply the new instance size while auto-scaling is enabled with effective fields, so the request still fails. ### API 1. Disable compute auto-scaling. Set `compute.enabled` to `false`. 2. Set the instance size to a value inside the intended new range. Set `instanceSize` to the target value, then send the request. 3. Re-enable compute auto-scaling. Set `compute.enabled` to `true`. 4. Set the new range bounds. Set `minInstanceSize` and `maxInstanceSize` to the new bounds, then send the request. ## MongoDB Support for Atlas Auto-Scaling If you have any questions or concerns, [contact support.](https://www.mongodb.com/docs/atlas/support.md#std-label-request-support)