# Right-sizing Atlas tier from cache and CPU metrics > Source-anchored research for Right-sizing Atlas tier from cache and CPU metrics. Run status: COMPLETED. Parent: [Storage and Data-Lifecycle Cost Levers](https://llms-explorer.com/tree/storage-and-data-lifecycle-cost-levers/) · 4 facets · 7 facts · page: https://llms-explorer.com/tree/right-sizing-atlas-tier-from-cache-and-cpu-metrics/ ## How it works - Atlas treats M10 and M20 CPU thresholds differently because cloud providers can cap CPU after burst periods; their scale-down thresholds use provider-specific baseline CPU. A generic CPU p95 cutoff such as the one in the OneUptime guide should not be applied unchanged across tier families. (medium confidence) (verified as of 2026-10-19) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) ## Measurements and reference values - Atlas Core reactive scale-down uses multiple signals across both 10-minute and 4-hour windows: operational nodes must average below 45% normalized System CPU, below 90% of maximum WiredTiger cache use, and below 60% projected memory utilization on the next lower tier. MongoDB's manual cost guidance separately calls for reviewing CPU, cache, memory, and IOPS together. (high confidence) (verified as of 2026-10-19) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core/) ## Comparisons and alternatives - For manual right-sizing, Atlas recommends monitoring CPU, WiredTiger cache, memory, and IOPS over a rolling 30-day period of normal use; sustained use below 45% of allocated resources is a general signal to consider scaling down. A OneUptime guide recommends a two-week baseline, so that shorter window should be treated as practitioner advice rather than Atlas policy. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/atlas/architecture/current/cost-saving-config/) - Cache hit rate is not a safe standalone tier gate. MongoDB says the working set does not have to fit entirely in RAM because WiredTiger evicts pages and the OS filesystem cache can hold compressed data. Guy Harrison also notes that a high cache hit ratio can coexist with an inefficient workload that repeatedly reads the same blocks. Atlas scale-down checks use cache occupancy and projected memory rather than a cache hit-rate threshold. (medium confidence) — [source](https://www.mongodb.com/docs/manual/faq/diagnostics/) - Assess WiredTiger cache pressure with multiple signals instead of cache occupancy alone. Atlas exposes cache and dirty-fill metrics alongside disk IOPS and latency; Percona's WiredTiger monitoring guidance says sustained high read-into-cache indicates the working set is not fitting in cache, and sustained dirty-page eviction can delay operations. Near-maximum cache use or rising disk reads therefore warrants checking query latency and I/O before downsizing, even when CPU is low. (high confidence) — [source](https://www.mongodb.com/docs/atlas/review-available-metrics/) - A candidate tier must also fit workload limits beyond CPU and cache: Atlas says connection capacity depends on tier, network bandwidth varies by instance, and disk IOPS should be compared with the provisioned maximum. Check those constraints and workload latency expectations before selecting the smaller tier. (medium confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/atlas/sizing-tier-selection/) ## Facts and statements - Treat a tier reduction as a measured change with a rollback path. MyDBOps recommends a 30-day CPU, memory, and IOPS baseline and remeasurement after resizing; OneUptime suggests a 14-day baseline and post-change monitoring. These are practitioner recommendations with different windows, so neither duration nor its suggested CPU cutoff is a universal safety guarantee. (medium confidence) (verified as of 2026-08-07) — [source](https://www.mydbops.com/blog/how-to-reduce-mongodb-atlas-costs-at-scale)