MongoDB Atlas had a 2h 11m incident on 30 September 2026 that delayed cluster management operations and made healthy clusters look degraded in the Atlas UI. The fault sat in MongoDB's own metrics ingestion pipeline, not in your clusters.
Started
18:51 UTC
Duration
Lasted 2h 11m
Source
IsDown
Next time
MongoDB is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: MongoDB Cloud
What happened?
MongoDB's status page opened this incident at 18:51 UTC, describing an issue with Atlas metrics ingestion that could delay cluster management operations such as cluster creation and modification. At 19:01 MongoDB identified the cause as a metric ingestion problem affecting some customers, and was explicit that clusters could appear degraded in the Atlas UI even though cluster health itself was unaffected. That distinction matters: this was a monitoring and display fault inside Atlas, not a data-plane failure of the clusters themselves. By 19:26 MongoDB reported a fix was in place, with latency returning to normal and incorrectly flagged clusters beginning to update their status correctly. The incident was marked resolved at 21:02 UTC, giving a total duration of 2h 11m across four published updates. Only one component is listed as affected: MongoDB Cloud. No user reports were filed during the window on this page's record. MongoDB's own account is the only source for what happened, and it covers the full arc from investigation to identification to fix to resolution, so it carries real weight even without outside confirmation. Over the past 90 days MongoDB has logged 17 incidents with a median duration of 4 hours 7 minutes, and across its history it averages 6.2 incidents a month, so a two-hour metrics delay sits on the shorter end of its typical pattern.
Learning
This incident shows a failure in Atlas's management and observability layer rather than in the database engine serving your queries, which is why the Atlas UI could show clusters as degraded while the clusters themselves kept running normally. If you were only watching your own application's connection to MongoDB, you would likely have seen nothing wrong, because your queries were never the part that broke. The fault lived upstream, in MongoDB's metrics ingestion pipeline, a layer you have no direct visibility into from inside your own product. In UptimeRobot's own 30 day window, 5 incidents were recorded against this provider with a median duration of 4h 25m, a reminder that provider-side issues of this shape recur on a schedule you don't control. Your own health checks tell you whether your application can reach the database, but they say nothing about whether the provider's control plane or dashboards are accurate. That gap is exactly where incidents like this one hide. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
