Understanding 5 Key MongoDB Atlas Alerts: What They Mean and How to Respond

MongoDB Atlas ships with a large set of built-in alerts, but a lot of teams turn them on without fully understanding what each one actually means. The result is either alert fatigue or missed signals.

This article walks through a small set of high-value alerts and explains them in practical terms. Not just what the metric is, but what it usually means in a real system, what tends to trigger it, and what you normally look at first when it fires. This article focuses on alerts in MongoDB Atlas, but the underlying concepts apply to MongoDB deployments more broadly.

In practice, most investigations follow the same flow: start with the alert, check events to understand what changed, use metrics to see the impact, and then drill down into profiler data and query plans to find the cause.

We will cover query efficiency signals, compute pressure, connection limits, memory pressure, and basic availability. The goal is to make each alert easier to interpret, so when it shows up, you already know what kind of problem space you are in and where to start looking.

What we will cover:

If you want to follow along and level up as you go, we’ll be using tools like the Query Profiler, Performance Advisor, and metrics throughout this guide. You can go deeper and earn a skills badge to prove your knowledge here, with the Monitoring & Tooling skills badge.

Query targeting is a query efficiency signal. It tells you how much work MongoDB is doing compared to how many documents your queries actually return. It is expressed as a ratio, such as documents scanned vs documents returned, or index keys scanned vs documents returned.

In simple terms, it answers a very practical question: are your queries going straight to the data they need, or are they digging through large parts of the collection to find a few matches?

If a query returns 5 documents but has to scan 10,000 to find them, that is poor targeting. The database is doing a lot of extra work for a small result set. High ratios usually point to missing indexes, weak indexes, or query shapes that are too broad.

It’s also worth calling out that this is usually an early warning. You’ll often see query targeting alerts before CPU or latency issues show up.

The alert fires when the scanned-to-returned ratio (documents examined vs. returned) crosses a configured threshold over a sampling window. This is averaged across operations, not based on a single bad query.

There are two common variants:

They’re telling you slightly different things, but the idea is the same: how much work is being done to produce a result.

When a query has to read a large number of documents to return just a few, you’ll see it reflected here:

The most obvious case is a full collection scan (COLLSCAN). If there’s no useful index for the query, MongoDB has no choice but to walk the collection to find matches.

What catches people out is that this can still happen even when an index exists. If the index doesn’t match the query shape well, MongoDB may still end up scanning a large number of documents.

At this point, you know something is inefficient, but not what yet. That’s where the next step comes in.

When this alert fires, don’t jump straight to adding indexes. First, figure out what changed. Did a new query or feature just get deployed? Did traffic shift? Did a batch job start running? Then narrow the scope. Is this tied to one collection or showing up across several? If it’s isolated, that’s a much easier investigation. If it’s broad, you’re likely dealing with a pattern rather than a single query.

From there, move into the tools that actually show you what’s happening.

Start with the Query Profiler. You’re looking to see whether slow queries line up with the timing of the alert. If they do, you’ve got something concrete to work with.

The Performance Advisor is useful for quickly spotting obvious missing index cases. It won’t solve everything, but it often points you in the right direction early.

If you need to understand where the load is concentrated, Namespace Insights helps you see which collections are doing the most work.

At that point, you’re usually down at the query level. Use explain() to inspect what MongoDB is actually doing. If you’re seeing COLLSCAN, large numbers of examined documents, or expensive sort stages, you’ve found the inefficiency. The explain plan docs are the reference if you need help reading the output.

Logs can help confirm things as well. You’re not digging for edge cases here, just checking whether collection scans or slow operations line up with the alert.

The important shift here is mindset. This alert is not the diagnosis. It’s the pointer. It tells you queries are inefficient, and then you use these tools to find which ones.

Most of the time, this comes back to indexing. If MongoDB is scanning far more documents than it returns, it usually means the query doesn’t have a good path into the data.

Start by checking whether your indexes actually match your common query patterns. If a query filters on certain fields but the index doesn’t support them, MongoDB will still end up doing extra work. The indexing strategies guide is the right place to go deeper if needed.

If you want to level up here, it’s worth learning how to design and optimize indexes properly and earning a skills badge you can share to prove your knowledge. Check out Indexing Design Fundamentals.

Compound indexes matter here as well, especially when queries involve both filtering and sorting. Even if an index exists, it may not be useful if the field order doesn’t match how the query runs.

The Performance Advisor can suggest missing indexes and is a good starting point, but it’s still worth reviewing suggestions rather than applying them blindly.

If indexing looks reasonable, move to query shape.

Sometimes the issue is that the query itself is too broad. Filters are too loose, ranges are unbounded, or too much data is being returned. Tightening queries often has a bigger impact than expected.

That usually means:

The query optimization guide is useful if you want a broader reference, but most fixes here are very local to specific queries.

There are also a couple of operational things to keep in mind. Background processes, particularly around MongoDB Search, can affect scan-style metrics, so it’s worth confirming what you’re seeing is coming from your application queries. And if you have heavy scan-style workloads, separating them from user-facing traffic can make a noticeable difference.

If you want to work through this properly, the main tools you’ll keep coming back to are:

Atlas gives you a default configuration out of the box, and that’s a good place to start. If you do want to tune it, think of it as deciding what “bad” looks like for your system.

As a general guide, MongoDB recommends setting this alert when the ratio rises above something like 50 or 100. That’s a much earlier signal than the older, very high thresholds some teams are used to, and it’s usually where inefficient queries start to show up.

The right configuration depends on how sensitive your system is to performance issues. User-facing workloads usually need earlier signals than internal or batch systems.

This alert is most useful when inefficient queries have a real impact.

That usually means production systems, user-facing workloads, or anything where performance degradation compounds over time.

It’s also helpful in systems that are still evolving. If query patterns are changing frequently, this will catch inefficiencies early.

In dev or batch-heavy environments, it’s less critical. You’ll either tune it higher or ignore it entirely.

The normalized CPU metric shows how much CPU your cluster is using, scaled from 0–100% based on the number of cores.

In plain terms, this tells you how busy your database is doing actual work.

If the normalized CPU is consistently high, MongoDB is spending most of its time actively computing: parsing queries, scanning documents, sorting results, and running aggregations. It is not waiting on I/O or sitting idle. It is working.

That distinction matters. High CPU is not just “load,” it is a compute-heavy load. Something is asking the database to do a lot of work per operation.

Short spikes in CPU are normal. Queries come in bursts, workloads fluctuate.

What you care about is sustained usage.

If the CPU sits high for a prolonged period, the system is under continuous pressure. That usually means one of two things:

This alert is designed to catch the second-order effect. It does not tell you which query is expensive, only that the system is busy doing work.

The alert fires when CPU usage stays above a configured threshold for a defined time window. Its main focus is sustained time under pressure, and not about short spikes in high CPU usage.

Typical real causes include:

When configuring alerts, avoid treating Normalized System CPU as something with a single “healthy” range. These thresholds are guidance, not targets, and should be tuned to your workload.

For many systems, teams might start with a threshold in the mid-range (e.g., 40–70%) as a baseline for sustained usage, but this is only a starting point. The right value depends on how your application behaves under normal load.

In practice, you’re looking for sustained deviation from your baseline rather than a specific number. If CPU usage remains elevated over time and is paired with increasing latency or slower queries, that’s when the alert becomes meaningful.

For a more detailed explanation of CPU metrics and how to interpret them in different environments, refer to the MongoDB documentation guidance for monitoring and alerts.

One nuance worth calling out: underlying infrastructure can affect how the CPU behaves, especially on burstable instances. When CPU credits run out, performance can drop off quickly even if your workload hasn’t changed.

In Atlas, this often shows up as CPU Steal. That’s the time your node is ready to run, but waiting on actual compute. If you’re setting CPU alerts, it’s worth keeping an eye on this alongside Normalized CPU, particularly if you’re on burstable tiers.

This is less about toggling a setting and more about defining what “too busy” means for your system.

The key decision is sensitivity. If your application is user-facing, you want earlier signals. If it is batch or internal, you can tolerate a higher sustained CPU before alerting.

This alert is most useful where performance degradation has a real cost. Operating on a suboptimal tier could result in higher costs if overprovisioned or potential downtime due to a lack of resources if underprovisioned. Selecting the appropriate tier will help ensure consistent performance at a minimum cost, assuming generally efficient use of computational resources.

That typically means you’ll want to configure when focusing on:

In dev or test environments, you’ll usually set a higher threshold to avoid noise.

For spiky batch workloads, the duration window becomes important. You want to catch sustained pressure, not expected bursts.

Treat this alert as a symptom, not a root cause.

Start with a few simple questions:

At this point, move into the tools that explain why the CPU is high.

Start with the MongoDB Query Profiler. This shows you whether slow or expensive queries line up with the CPU spike. If they do, you’ve found your entry point.

The MongoDB Performance Advisor helps identify missing or inefficient indexes that may be causing extra work.

Use MongoDB Namespace Insights to understand which collections are driving the load. This is especially useful when CPU is high, but the source is unclear.

Then drop down to query-level inspection with explain(). You’re looking for:

Start with query efficiency. CPU problems are very often query problems first.

Look at indexing. If queries are scanning large portions of a collection or sorting in memory, they will consume CPU quickly. Focus on:

The MongoDB indexing strategies guide is the right place to go deeper if needed. Then look at the query shape.

Even with indexes, queries can still be too broad or expensive:

The MongoDB query optimization guide is useful as a reference, but most improvements here are small, targeted changes.

If query efficiency looks reasonable, move to capacity.

Connection percentage tells you how close your cluster is to its maximum number of allowed client connections.

It is expressed as a percentage of the configured connection limit for the cluster tier. MongoDB Atlas defines these limits per node, with a small portion reserved internally, and publishes them in the Atlas limits documentation.

In simple terms, this metric answers a very practical question: Are you running out of room for new connections?

If the percentage is high, it means a large number of clients are already connected, and there is less headroom for new requests. If it reaches the limit, new connections can be rejected, which usually shows up as application errors rather than gradual degradation.

This is not a query efficiency signal. It is a capacity and behavior signal.

This is one of the more straightforward alerts to interpret. A low or moderate connection percentage is normal. Applications maintain connection pools, background services stay connected, and traffic fluctuates.

What you care about is sustained high usage. If the connection percentage climbs and stays high, the system is operating close to its connection ceiling. That is where problems start to appear under load or during spikes.

The alert fires when the connection percentage exceeds a configured threshold for a defined period of time.

It is typically recommended to alert somewhere around 80–90% of the connection limit, as described in the Atlas alert basics documentation.

Like the other alerts, this is about sustained pressure, not brief spikes.

Typical real causes include:

Atlas’s own guidance highlights connection pooling and application behavior as the most common root causes, with scaling the cluster as the fallback when capacity is genuinely insufficient, covered in the connection alert resolution guide.

Think of this alert as a safety margin, not a binary switch.

The key decision is how much headroom you want. User-facing systems should alert earlier to avoid hard failures. Internal systems can tolerate being closer to the limit. Full configuration guidance is available in the alert configuration documentation.

This alert is most useful where connection exhaustion would cause real issues.

That typically means:

In dev or test environments, you will usually set a higher threshold to avoid noise.

When this alert fires, start with behavior, not infrastructure. First, check the Connections metric in Atlas and look at the shape of the increase.

Is it a sudden spike or a steady climb? Then ask a few key questions:

If connections increase and never come down, that often points to pooling or connection lifecycle issues. If connections track traffic closely, it may simply be a capacity problem. At this point, shift your focus to the application.

Atlas explicitly recommends checking connection handling and pooling behavior in the application as the first step, as described in the connection alert resolution docs.

Look at how your driver is configured:

These patterns can multiply connections quickly, even if each individual service looks fine in isolation.

If you are already near the limit and need to reduce pressure quickly, there are a few short-term options.

These are documented in the connection alert resolution guide. These actions buy you time. They do not fix the underlying issue.

Most fixes fall into three categories.

First, connection handling. Make sure your application is using proper connection pooling and not creating excessive clients. Atlas explicitly recommends enabling and tuning pooling as the first step when nearing connection limits, as described in the Atlas limits and scaling guidance.

Second, pool sizing and architecture. Even with pooling, total connections can grow too large when:

Reducing per-instance pool sizes can have a large impact.

Third, capacity. If the application behavior is correct and the workload is legitimate, the cluster tier may simply be too small.

Atlas notes that higher tiers support more connections and that upgrading the cluster or enabling autoscaling is the correct path in these cases, covered in the connection alert resolution documentation.

System memory percent tells you how much of the host machine’s RAM is currently in use.

It is the total memory used by everything on the node. In practice, this answers a simple question: is this machine running out of memory headroom?

MongoDB is designed to take advantage of memory heavily. The more of your active dataset (your working set) that fits in RAM, the faster queries will be. Once memory gets tight, the operating system starts reclaiming cache, and MongoDB has to fetch more data from disk instead of memory.

That is where performance starts to change. Queries that were fast become slower, and you will usually see disk read activity increase at the same time. The Atlas metrics documentation is useful for seeing how memory and disk behavior line up.

Memory usage rising under load is normal. What matters is whether it stays high.

If the system memory percent is consistently elevated, the node is operating with very little free memory. That means cache effectiveness is reduced, and more operations will depend on disk access.

The alert fires when total system memory usage crosses a configured threshold for a sustained period of time. It reflects overall pressure on the node and is not tied to a single query or operation.

Common causes tend to fall into a few patterns:

One important signal is correlation. High memory usage on its own is not always a problem. High memory usage combined with rising disk reads usually is.

Think of this as an early warning, not a hard failure signal.

You are trying to catch sustained pressure before it impacts performance.

Atlas provides general guidance in the alert configuration documentation. The key decision is sensitivity. If your workload is latency-sensitive, you want to know earlier. If not, you can tolerate higher sustained usage.

This alert matters most when memory directly affects performance.

That usually means:

It is less important for small datasets or low-traffic environments where everything fits comfortably in memory. The closer your working set is to your available RAM, the more valuable this alert becomes.

Start with trends. Is memory usage steadily high, or is it climbing over time?

Then look for changes:

Next, correlate with other metrics. The Atlas cluster metrics will show you memory, disk I/O, and cache behaviour together.

If disk reads are increasing alongside memory pressure, it is a strong signal that your working set no longer fits in memory.

From there, move to query-level inspection. Use the Query Profiler to identify large or memory-heavy operations. You are looking for queries or aggregations that touch large portions of the dataset or require significant in-memory work.

At this point, you are not diagnosing a single query yet. You are narrowing down what is driving overall memory pressure. This alert is the signal. The profiler and metrics are how you find the cause.

Start with how data is being accessed.

Memory pressure is often a side effect of queries reading too much data.

On the query side:

The indexing strategies guide and query optimization guide are the right places to go deeper if needed.

Then look at the data itself.

Indexes consume memory too, so unnecessary ones add pressure without helping performance.

If workload and data look reasonable, then it becomes a capacity question.

Read more about scaling and capacity considerations in the cluster metrics and performance documentation.

A host down alert tells you that a node in your cluster became unreachable. At a specific moment in time, Atlas expected to be able to communicate with a node and couldn’t. That’s all this alert really is. It doesn’t try to infer why, it just reports what it can see: “I expected this node to be available, and I couldn’t reach it.”

That distinction matters because the root cause isn’t always MongoDB itself.

Sometimes it is. Sometimes it very much isn’t.

In practice, you can think about this alert as collapsing down into a few possibilities. Either the node restarted, the underlying host became unavailable, or there was a network interruption. Everything you do from here is just narrowing that down as quickly as possible.

It’s also worth keeping in mind that this is based on periodic checks. So what you’re seeing is a snapshot. The system checked, couldn’t reach the node, and raised the alert. It doesn’t mean the node has been down continuously, just that it was down at the moment it mattered.

Start with timing. Did this happen during a deployment, a scaling event, or a spike in traffic? Atlas gives you an Activity Feed and Events view for exactly this reason. You’re looking for anything that lines up with the alert, such as node restarts, maintenance events, or failovers. You can see a list of possible events and what they mean in the MongoDB docs here.

If you see a primary election around the same time, that’s expected behavior in a replica set. The system lost a node and recovered. That’s a degraded state, not necessarily a full outage.

Start in the Events view. You’re looking for something concrete, like a primary election, a node restart, or a state change. That tells you what happened.

From there, go to the cluster metrics. This is where you see what it did to the system. You won’t see a label saying “node down,” but you will see the moment something changed.

Check a few key graphs at the same point in time. Connections will often drop and recover as clients reconnect. Latency may spike briefly while the system stabilizes. Operation throughput can dip if work is interrupted during the transition. In the process view, you may see a node flatline or disappear before coming back.

You’re not looking for a single signal here. You’re looking for multiple graphs shifting at the same moment. That’s usually where the node dropped out, and the cluster recovered.

Once you’ve found that moment, look just before it. This is where you start to understand why it happened. CPU spikes can point to overload. Memory pressure can point to instability. Disk activity can suggest heavy workloads. Connection growth can indicate rising pressure on the system. You’re trying to understand what led up to the event, not just the event itself.

At this point, you’re not debugging a process directly. You’re building a picture of whether this was a brief interruption, a node-level issue, or something affecting the wider cluster.

This alert isn’t a perfect signal of uptime. Because it depends on periodic checks, short interruptions can go unnoticed, and brief blips can sometimes trigger alerts if they happen at the wrong time. So you shouldn’t treat this as a complete picture of availability. It’s a useful signal, but it needs context from metrics and events.

If you need a fuller view of availability over time, that comes from combining alerts with the cluster metrics and the Events view, rather than relying on a single alert firing.

Once everything is stable again, it’s worth stepping back and asking why this happened at all.

In most cases, the longer-term fixes fall into a few familiar areas. Make sure the cluster has enough CPU and memory headroom. Avoid sustained resource pressure that can destabilize nodes. Understand whether certain workloads or traffic patterns are triggering restarts or failovers.

If you’re seeing primary elections, it’s worth understanding how replica sets behave under failure. MongoDB will automatically elect a new primary when one becomes unavailable, which is what allows the system to recover without a full outage. The replication docs are a good reference if you want to go deeper on how that works.

If you’re running a replica set, this usually shows up as a degraded state that the system recovers from. If you were running a single node, the same event would have been a full outage. That’s an important distinction when you’re thinking about resilience.

After resolving the issue, don’t just move on immediately. Watch the system for a bit.

Look for repeated node restarts, ongoing instability in metrics, or patterns that suggest the issue wasn’t a one-off. The cluster metrics are especially useful here. You’re looking for the same signals as before, just over a longer window.

Network-related signals, in particular, can be useful. Latency spikes, inconsistent throughput, or connection churn can all point to underlying instability even if the database appears healthy again.

A Host Down alert can feel abrupt, but once you break it down, it becomes a very structured process. You’re just working through a sequence: what changed, what does the cluster look like now, and what was happening just before it occurred. Once that flow becomes familiar, it stops being a panic moment and starts becoming routine.

If you’re running MongoDB outside of Atlas, this is the point where you’d drop down to checking the mongod process directly and verifying host-level connectivity, as covered in the replica set troubleshooting guide.

In Atlas, that layer is managed for you. Your job is to interpret the signals and understand what the system is telling you, not to log into the machine. If you need extra help, you can check out MongoDB support.

These alerts are best treated as signals, not verdicts. Each one points to a class of problems rather than a single root cause. Query targeting points to inefficient query shape or indexing. Normalized CPU points to compute pressure, often driven by query patterns. Connection percentage usually points back to the client pool configuration. System memory percent highlights cache and working set pressure. Host down is a straight availability incident.

In practice, the useful workflow is consistent: treat the alert as a direction, then move to profiler data, metrics charts, and query plans to find the specific source. Over time, you will also tune thresholds so that alerts fire early enough to act on, but not so early that they become background noise.

Used this way, alerts become a guide to where to look next, not just another dashboard light turning red.