Report this

What is the reason for this report?

Database does not respond and cannot be restored. What can I do?

Posted on July 17, 2026

I have a managed MongoDB that stopped responding. It’s not reachable anymore from anywhere. The status in the Control Plane shows green but when I look at the details I cannot see any databases anymore and get timeout errors. Also, the insights (CPU, memory, …) stopped reporting hours ago.

I tried to restore from a backup to a new cluster twice. First time the new cluster just vanished. The second attempt has been hanging for hours now. I opened a ticket with the support but they auto-closed telling me my STMP restrictions have been lifted. This has nothing to do with SMTP! I reopened the ticket but haven’t heard anything since. What can I do? I need that database back…



This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

0

Accepted Answer

Hey @raphaelstaebler,

That combination (panel showing green, but no databases visible, timeouts, and Insights that stopped reporting hours ago) points at the cluster node being wedged on DigitalOcean’s side, not anything in your config. When Insights goes silent it usually means the underlying host stopped responding, and that isn’t something you can fix from the control panel. So the honest answer is this one has to go through support, because only their database team can look at the node and either recover it or force a rebuild.

A couple of things that’ll help in the meantime. Stop launching new restore attempts. A second or third restore hanging on top of a stuck one just makes it harder for them to see what state things are in, and the vanishing new cluster suggests provisioning itself is failing right now, so piling on won’t get you a good copy. If you have an older daily backup, note its exact timestamp so you can ask them to restore that specific one to a fresh cluster, ideally in a different region in case the problem is localized to the current one.

On the ticket, the auto-close was a wrong macro. That SMTP reply has nothing to do with your issue, so reopen it and lead with the exact framing: production managed MongoDB unreachable, possible data loss, restores failing. Include the cluster ID, the region, and roughly when Insights stopped reporting. That severity wording genuinely matters, it’s the difference between landing in the normal queue and getting routed as an outage. If you’re on a paid support plan, there’s usually a priority path worth using here.

You can get it back in front of them here: https://www.digitalocean.com/support/

I know that’s frustrating when you just want the data back, but a wedged managed node really is a support-side fix, and a clearly worded ticket with the cluster ID is the fastest way there.

Heya, @raphaelstaebler

Two things worth doing before or alongside that reopened ticket. First, check status.digitalocean.com for your specific region right now, DigitalOcean’s status page has been actively tracking regional incidents recently, a Reserved IP routing issue in TOR1 and DNS timeouts affecting DOKS in NYC1 both got posted there this month, so if something broader is going on with your region it’ll likely show up there, and having an incident reference to point to in your ticket speeds things up. If nothing’s posted, that lines up with KFSys’s read of this being an isolated wedged node rather than a wider outage.

Second, if you’re not already on a paid support plan, it’s worth checking. DigitalOcean’s documentation notes response times scale with support tier, and Premium support carries a 30 minute response target for production-down situations with a dedicated technical advisor handling escalation, which matters here given the free tier ticket already got mishandled once. Between the region, cluster ID, and backup timestamp KFSys already told you to include, and pushing this through the right support tier, that’s the fastest path to someone who can actually unwedge the node.

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Start building today

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.