MongoDB Atlas statusLiveFetched seconds agoSource: status.mongodb.com
Is MongoDB Atlas down?
Live status check · All systems operational
Live status pulled from status.mongodb.com, cached and revalidated every 60 seconds. Below: the components that can break, what to do during an incident, and how to keep your scheduled jobs running independently.
About MongoDB Atlas status
MongoDB Atlas is the managed MongoDB cloud, covering the database plus Atlas Search, Atlas Vector Search, and Atlas App Services (Functions and Triggers). Incidents are almost always scoped to one cloud region or one component, so a status-page red banner rarely means every cluster everywhere is down.
Components and surfaces that can break
- Surface 01
Per-cluster availability across multi-cloud regions (AWS, GCP, Azure).
- Surface 02
Atlas Search and Atlas Vector Search indexes.
- Surface 03
Atlas App Services: Functions, Triggers, and Device Sync.
Recent MongoDB Atlas incidents
MongoDB Atlas maintains a public incident history. Read the latest entries to see whether you're hitting a known issue, and look at the post-mortems for context on how long similar incidents typically take to clear.
What to do if MongoDB Atlas is actually down
Pin the incident to your cluster's cloud and region
Atlas runs on AWS, GCP, and Azure across dozens of regions. Find your cluster's provider and region in the Atlas console, then match it against the status page. If your cluster is a multi-region replica set, the driver can read from a healthy secondary while the primary region recovers.
App Services and the database are different layers
Atlas Functions and Atlas Triggers run on a separate App Services layer, not on your cluster. A Triggers outage does not mean your application's queries are failing, and a database blip does not always stop Functions from executing. Check both components on the status page before assuming one took the other down.
Expect a connection-pool stampede on recovery
When a region comes back, every app instance reconnects at once and replica sets renegotiate primaries. Cap your driver's maxPoolSize, keep retryWrites and retryReads enabled, and add a small jittered backoff on reconnect so you do not flood the cluster the moment it becomes reachable again.
Keep firing through the incident
Schedule your own MongoDB Atlas health check with Crontap
Scheduled Atlas snapshot exports, hourly Atlas Search index refreshes, and scheduled aggregation pipeline runs are all just HTTP cron when wrapped in a small endpoint. Crontap fires the /jobs/run endpoint that opens the Mongo connection, runs the work, and returns a 5xx on failure so the alert email contains the actual driver error instead of a silent miss.
External HTTP cron hits your endpoint on the cadence you pick, stores every response, and emails you the moment a run fails. Pro schedules down to 1 minute; $3.25/mo annual flat for unlimited jobs.
Go deeper
MongoDB Atlas status: FAQ
- Where can I see the official MongoDB Atlas status?
- status.mongodb.com is the official status page. It publishes component status for Atlas database clusters, Atlas Search, Atlas App Services, and the Atlas UI, broken down per cloud provider and region. The history page lists past incidents with timestamps and post-mortems, and there is an Atom feed at status.mongodb.com/history.atom for subscribing.
- Will my Atlas Triggers still fire during a database outage?
- Often yes. Atlas Triggers run on the App Services layer, which is separate from your cluster. Scheduled Triggers can still fire on time, but database Triggers that depend on change streams from an impacted cluster will pause and then replay once the cluster recovers. Check the App Services component on the status page separately from the database component.
- How do I scope an Atlas incident to my cluster's region?
- Open your cluster in the Atlas console and note the cloud provider and region (for example AWS us-east-1 or GCP europe-west1). Then filter the status page to that provider and region. If the incident is in a different region, your cluster is healthy and the failure is somewhere else, usually your driver config, network egress, or IP access list.