MongoDB status

How we check MongoDB

We watch cloud.mongodb.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the Atlas control plane, the host that serves the cloud console and its API, because it is the only part of a managed database service that can be checked honestly from outside without credentials. Your own cluster's endpoint answers only to authorised network access, so a public probe against it would measure our firewall rules rather than MongoDB's health.

What is MongoDB?

MongoDB Atlas is the managed version of MongoDB, and for most teams running MongoDB today it is simply what MongoDB means. Clusters are provisioned, backed up, patched, scaled, and monitored by MongoDB rather than by the team using them, which removes an entire operational burden and, in exchange, introduces a dependency that is worth understanding before it fails.

The most useful thing to know is that a managed database has two distinct surfaces, and they fail separately. The control plane covers the console, the administrative API, metrics, backups, and anything that changes the shape of your deployment. The data plane is the connection your application opens to run queries. When the control plane is degraded, you cannot resize a cluster, restore a snapshot, or look at a dashboard, but your application usually carries on querying without noticing anything at all. Treating a console outage as a database outage causes unnecessary panic, and occasionally causes real harm when someone starts failing over in response to a problem that was never affecting traffic.

The second thing worth internalising is how many apparent MongoDB outages are network configuration. Atlas clusters accept connections only from addresses on an access list or through a private network peering, which is a good default and a reliable source of confusion. A new application server, a CI runner with a rotating address, a NAT gateway that changed, or a peering route removed during unrelated cloud work will each produce a connection timeout that looks exactly like a database being down. Nothing in the error distinguishes "the database is unavailable" from "the database is refusing to talk to you specifically", which is why an outside signal that the platform is healthy is worth having before starting a deeper investigation.

Performance problems are the third category, and they are almost never platform incidents. A query that was fast last month and is slow today usually reflects data that grew past the point where an index helped, a working set that no longer fits in memory, or a connection pool exhausted by a service that was scaled up. These degrade gradually rather than failing outright, so they rarely coincide with anything anyone publishes, and they respond to profiling rather than to waiting.

For workloads that genuinely cannot tolerate downtime, the architectural answer is the same as it is for any cloud service. Atlas incidents are usually scoped to a single cloud provider in a single region, so a deployment spread across regions survives them, and one that is not can only wait. Knowing which region your cluster actually runs in is a surprisingly common gap and the first fact worth checking when an incident is announced.

Frequently asked questions

Is MongoDB Atlas down right now?

Check the board above; it reflects our own probes against the Atlas control plane from all five of our regions, refreshed every couple of minutes. This measures whether MongoDB's cloud platform is reachable, not whether your particular cluster is healthy.

My application cannot reach my cluster but this page shows MongoDB up. Why?

Because a cluster is reachable only from networks you have allowed, so most connection failures are configuration rather than outage. An IP access list that does not include your new server, a VPC peering route that changed, a connection string still pointing at an old cluster, or a database user whose password was rotated will all produce a connection failure while Atlas itself is entirely healthy. The Atlas console shows your cluster's own state, which is the reading that matters here.

Does an Atlas control plane outage take my database down?

Usually not, and this is the most reassuring thing to know during an incident. The console and the administrative API are separate from the data path your application uses, so a control plane problem typically means you cannot create clusters, change configuration, or read metrics, while your running application keeps querying its database normally. It is a bad time to make changes and not necessarily an outage for your users.

Why did my queries get slow without any deploy on my side?

Most often because of something inside your own cluster rather than the platform. A collection that outgrew its index, an autoscaling event, a background compaction, a change in data distribution, or simply approaching the connection limit will all slow queries down with nothing wrong at MongoDB. The Atlas performance advisor and the slow query log are the right places to look before treating it as an outage.

Do Atlas incidents affect all cloud regions at once?

Rarely. Atlas runs on the major cloud providers across many regions, and an incident is usually scoped to one provider in one region, which is exactly why a multi-region deployment is the standard answer for workloads that cannot tolerate downtime. Check which region your cluster is in before assuming a published incident applies to you.