MongoDB Charts got stuck in an infinite login loop on 2026-10-02, blocking anyone trying to create a new Charts project for just over five hours. The fault sat on MongoDB's side, inside the Charts visualisation flow, not with existing projects or any code you wrote.
Started
00:01 UTC
Duration
Lasted 5h 2m
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.
What happened?
MongoDB's status page says the trouble began around 23:30 UTC on 2026-10-01, though the incident itself is logged as starting at 00:01 UTC on 2026-10-02. Anyone clicking the Visualization tab to spin up a new Charts project was repeatedly bounced back to a login prompt and could never actually reach the Charts interface. MongoDB's own update is careful to note that these projects were still being created in the background, just without a guaranteed view of the result, and that existing Charts projects were unaffected throughout. That is the full extent of what MongoDB published: one identification notice at 00:01 UTC and a resolution notice at 05:02 UTC, with nothing in between describing what actually broke in the login flow. No cause is given anywhere on the record, so it is not possible to say whether this was an authentication service problem, a session handling bug, or something else entirely. The incident ran for 5 hours and 2 minutes before MongoDB marked it resolved. No components are listed as affected in MongoDB's own breakdown, which lines up with this being scoped narrowly to new Charts project creation rather than the wider platform. No user reports came in during the window on this page, so the only account of impact is MongoDB's own two-line log. Over the past 90 days MongoDB has logged 19 incidents with a median duration of 4 hours 23 minutes, and this one ran a bit longer than that typical span. Across all time MongoDB averages 6.2 incidents a month, 391 in total, so a single-incident day like this one is on the lighter end of its usual pattern.
Learning
UptimeRobot's own 30-day checks on MongoDB recorded 7 incidents with a median duration of 5 hours 8 minutes, a figure close to what played out here, which suggests this kind of extended login loop is not a one-off fluke but part of a recurring pattern on MongoDB's Charts feature. This particular fault lived entirely inside MongoDB's authentication and project-loading flow for Charts, a layer you cannot see or test from your own application code no matter how carefully you watch your own endpoints. If your product only pings your own servers and your own database connections, a loop like this one would never show up, because nothing on your side was broken. The failure was specific enough that it only hit new project creation and left existing Charts projects alone, which is exactly the kind of narrow, provider-side fault that generic uptime checks on your own stack are not built to catch. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
