# MongoDB status

> Is MongoDB Atlas down? Live status, uptime history, and per-region response times measured by our own probes rather than crowd reports.

Published: 2026-08-21 | Canonical: https://yoping.me/status/mongodb

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/mongodb. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.