> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Review Cluster Metrics

**Note:**

This page applies to both Atlas Infinite and Atlas Core.

Atlas collects and displays metrics for your servers, databases, and MongoDB processes.

Monitor cluster metrics to identify performance issues and determine whether your current cluster meets your requirements. For more information on the metrics available to monitor your clusters, see [Review Available Metrics.](https://www.mongodb.com/docs/atlas/review-available-metrics.md#std-label-review-available-metrics)

**Note:**

The number of servers that Atlas displays on the Metrics page at any given time depends on the browser screen size. Use the Toggle Members section to control which servers Atlas displays. Hover over the `S` and `P` icons to find out which servers they represent.

**Note: New Metrics UI Gradual Rollout**

Atlas is rolling out a redesigned Metrics UI to select new organizations. The new interface provides enhanced filtering, unified metrics views, and improved navigation. To learn more about the new experience, see [New Atlas Metrics UI.](https://www.mongodb.com/docs/atlas/metrics-ui-rollout.md#std-label-metrics-ui-rollout)

## View Metrics

[View Project Overview](https://www.mongodb.com/docs/atlas/review-all-cluster-metrics.md#std-label-review-all-cluster-metrics)

The Clusters view displays all the clusters in an Atlas project and features core metrics per cluster. You can also view core metrics for a specific cluster on the Overview tab.

[View Atlas Flex cluster Metrics](https://www.mongodb.com/docs/atlas/review-flex-metrics.md#std-label-review-flex-metrics)

View the metrics for a specific Flex cluster in an Atlas project.

[View Atlas Replica Set Metrics](https://www.mongodb.com/docs/atlas/review-replica-set-metrics.md#std-label-review-replica-set-metrics)

View the metrics for a specific replica set in an Atlas project.

[View Atlas Sharded Cluster Metrics](https://www.mongodb.com/docs/atlas/review-sharded-cluster-metrics.md#std-label-review-sharded-cluster-metrics)

View the metrics for a specific sharded cluster in an Atlas project.

[View MongoDB Processes](https://www.mongodb.com/docs/atlas/review-mongodb-process-metrics.md#std-label-review-mongodb-process-metrics)

View the metrics for a specific MongoDB process in an Atlas cluster.

[View Real-Time Performance Metrics](https://www.mongodb.com/docs/atlas/review-real-time-metrics.md#std-label-review-real-time-metrics)

View real-time performance metrics for a specific Atlas cluster in a project.

[View MongoDB Search Metrics](https://www.mongodb.com/docs/atlas/review-atlas-search-metrics.md#std-label-review-atlas-search-metrics)

View MongoDB Search metrics for Atlas clusters with at least one active MongoDB Search index.

## Important Metrics

You can monitor the following metrics to quickly gauge the health of your cluster.

| Chart | Description |
| --- | --- |
| Connections | Number that indicates the total active connections to the cluster. Monitor connections to determine whether the current connection limits are sufficient. If necessary, scale the cluster tier. To learn more, see [Fix Connection Issues](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/connection-alerts.md#std-label-connection-alerts) and [Fix Lost Primary.](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/no-primary.md#std-label-no-primary) Use [`$currentOp`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/currentOp.md#mongodb-pipeline-pipe.-currentOp) to determine which collections are using more connections in a cluster. For more details, see [Count Collection Connections.](https://www.mongodb.com/docs/manual/reference/operator/aggregation/currentOp/#count-collection-connections) |
| Disk IOPS | Number that indicates the input operations per second. Monitor whether disk IOPS approaches the maximum provisioned IOPS. Determine whether the cluster can handle future workloads. To learn more, see [Fix IOPS Issues](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/disk-io-utilization.md#std-label-disk-io-util) and [Fix Lost Primary.](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/no-primary.md#std-label-no-primary) |
| Disk Usage | Number that indicates the total bytes of used disk space for the cluster. Monitor the combined size of your data and MongoDB operational data (buffer, journal, and log files) on the cluster. IMPORTANT: The UI displays GB, but all disk usage metrics are in gibibytes (GiB). To learn more, see [Fix Storage Issues.](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/disk-space-used.md#std-label-disk-space-used) |
| Query Targeting | Number that indicates the efficiency of read operations run on MongoDB. Monitor query targeting metrics to identify inefficient queries. The [change streams](https://www.mongodb.com/docs/manual/changeStreams/) cursors that the MongoDB Search process (`mongot`) uses to keep MongoDB Search indexes updated can contribute to the query targeting ratio and trigger [query targeting alerts](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#std-label-query-targeting-alerts) if the ratio is high. To learn more, see [Fix Query Issues.](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/query-targeting.md#std-label-query-targeting-resolution) |
| Normalized System CPU | Number that indicates CPU usage of all processes on the node, scaled to a range of 0-100% by dividing by the number of CPU cores. Monitor CPU usage to determine whether to scale to a higher cluster tier. If you are unable to see the usage that triggered the alert, zoom in on the Normalized System CPU chart by clicking and dragging your mouse over the period of interest. With a higher-resolution view you may be able to identify acute spikes in CPU usage that weren't visible in the overview. To learn more, see [Fix IOPS Issues](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/disk-io-utilization.md#std-label-disk-io-util), [Fix Lost Primary](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/no-primary.md#std-label-no-primary), and [Fix CPU Usage Issues.](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/system-cpu-usage.md#std-label-system-cpu) |
| Oplog GB/Hour | Number that indicates the average rate in gigabytes of [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) data that the primary generates per hour. Monitor oplog data to determine whether you have to increase the oplog size. To learn more, see [Fix Oplog Issues.](https://www.mongodb.com/docs/atlas/reference/alert-resolutions/replication-oplog.md#std-label-replication-oplog-alerts) |

## Monitoring Data Storage Granularity

Atlas stores metrics data at various granularity levels. For each granularity level, Atlas computes metrics as averages of the reported metrics at the next finer granularity level.

**Example:**

At the end of a 60-minute period, Atlas generates a 1-hour metrics report. Atlas computes the value of the Connections metric in the 1-hour report as the average of all values for the Connections metric across the 60 1-minute reports that it generates in that hour.

Atlas gathers metrics data at a 1-minute granularity unless you qualify for premium monitoring. However, Atlas gathers Replication Lag and Replication Headroom metrics at an 85-second granularity.

When metrics data reach the end of their retention period, Atlas compacts them into a single unit of the next broader granularity level.

**Example:**

After 48 hours' worth of data is collected, Atlas compacts each group of 60 minutes into a single unit of an hour. After 63 days, Atlas compacts each group of 24 hours into a single unit of a day.

**Note:**

When you scale a cluster to M40 tier or higher, the cluster qualifies for premium monitoring. To view historical metrics data for your scaled cluster, you must adjust the granularity to one-minute intervals. This is because premium monitoring displays 10-second metrics granularity while basic monitoring displays 1-minute granularity.

## Burst Reporting

Many metrics have a burst reporting equivalent. The value of a burst reporting metric at a given granularity is the maximum reported value from all the reports Atlas generates at the next finer granularity level during that interval.

**Example:**

The Disk IOPS metric has a Max Disk IOPS equivalent. Atlas reports the Max Disk IOPS for a 1-hour interval as the highest Max Disk IOPS value across the 60 1-minute reports Atlas generated in that hour. Atlas reports the Max Disk IOPS for a 1-day interval as the highest Max Disk IOPS value across the 24 1-hour reports Atlas generated in that hour.

### Premium Monitoring Granularity

If you have at least one cluster that's `M40` or larger, Atlas automatically enables premium monitoring for all clusters in the project. With premium monitoring enabled, Atlas gathers metrics data at a 10-second granularity. Premium monitoring remains enabled for all clusters in the project until you downgrade or terminate your last `M40` cluster.

### Metrics Data Retention

Atlas retains metrics data for a period of time that depends on the granularity of the data:

| Data Period | Duration of Retention |
| --- | --- |
| 10 seconds | 8 hours |
| 1 minute | 48 hours |
| 5 minutes | 48 hours |
| 1 hour | 63 days |
| 1 day | Forever |

 [Premium monitoring](https://www.mongodb.com/docs/atlas/monitor-cluster-metrics.md#std-label-premium-monitoring) only.

Atlas retains all database-specific statistics. MongoDB log data is retained at a maximum rate of 2000 lines per 2 minutes.

**Note: Historical metrics carryover**

If you create a new cluster with the same deployment type, name, and project as a previously deleted cluster, the historic metrics for the deleted cluster are carried over to the new cluster.

## Free Cluster Monitoring Considerations

- Free clusters (formerly known as `M0`) and Flex clusters support a subset of the metrics and charts available. For complete documentation on the limitations of these clusters, see [Atlas Free Cluster Limits](https://www.mongodb.com/docs/atlas/reference/free-shared-limitations.md#std-label-atlas-free-tier) and [Atlas Flex Limitations.](https://www.mongodb.com/docs/atlas/reference/flex-limitations.md#std-label-flex-cluster-limitations)

- Atlas pauses monitoring for Free clusters which have had no connection activity for 7 days. Monitoring resumes once a successful connection occurs through the Atlas Administration API, [Driver](https://www.mongodb.com/docs/atlas/driver-connection.md#std-label-connect-via-driver), [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh), or [Data Explorer.](https://www.mongodb.com/docs/atlas/atlas-ui.md#std-label-atlas-ui)

## Manage Tags

You can add a tag, view existing tags, and manage tags from the Clusters page or the Overview page. To learn more, see [Manage Cluster Tags from the Clusters Page](https://www.mongodb.com/docs/atlas/database-deployment-tags.md#std-label-manage-tags-database-deployment-card) and [Manage cluster Tags from the Overview Page.](https://www.mongodb.com/docs/atlas/database-deployment-tags.md#std-label-manage-tags-overview-page)

**Important:**

Don't include sensitive information such as Personally Identifiable Information (PII) or Protected Health Information (PHI) in your resource tags. Other MongoDB services, such as Billing, can access resource tags. MongoDB also sends cluster resource tags to DataDog and Prometheus integrations. Resource tags are *not* intended for private and sensitive data. To learn more, see [Sensitive Information.](https://www.mongodb.com/docs/atlas/production-notes.md#std-label-sensitive-info)