MongoDB Atlas cluster paused: why it happens and how to stop it

Your app worked last month. Today every database call fails, and the Atlas dashboard shows your cluster as paused.

Nothing broke. MongoDB Atlas paused your Free cluster because nothing had connected to it in a while.

Here's why it happens, how to get it back, and how to stop it catching you out again.

MongoDB Atlas cluster paused: why it happens

Atlas automatically pauses a Free cluster after 30 days of inactivity, which MongoDB defines as zero connections to the cluster.

"Free cluster" is the current name for what used to be called M0. Same thing; the Atlas docs renamed it to match the dashboard.

Once paused, the cluster refuses every connection until you resume it. To your app, that looks exactly like the database being down.

30 days

with zero connections before a Free cluster pauses

7 days

warning email sent before the pause

0

connections allowed while it's paused

Flex

the paid tier Atlas never auto-pauses

The warning email you probably missed

Atlas emails you seven days before it pauses the cluster, and again once it has.

If that address is an old inbox or a filtered folder, the first you hear of it is a broken app.

Some people get the warning even though their app is busy. In one MongoDB community thread, the suggested cause was a different project with an idle Free cluster.

So before you panic, check which cluster and project the email actually names.

How to resume a paused MongoDB Atlas cluster

Resuming happens in the Atlas dashboard, not from your app:

1. Log in to MongoDB Atlas and pick the organization and project that own the cluster.
2. Open the project's Clusters page.
3. Click Resume on the paused cluster.

Once it's running again, your app can connect to it as before.

If Atlas won't let you resume it

There's one catch. Atlas can't resume a paused Free cluster that was running an older MongoDB version it can no longer restore to the current one.

In that case MongoDB's documented route is roundabout, and it costs money for a short while.

• Spin up a paid M10 cluster on the same MongoDB version and restore the Free cluster's backup snapshot into it.
• Upgrade that cluster, export with mongodump, and load the data into a fresh Free cluster with mongorestore.
• Delete the M10 so it stops billing you.

How to stop MongoDB Atlas pausing your cluster

You have two honest options.

How to stop it for good: upgrade off the Free tier

Atlas's docs say it doesn't automatically pause inactive Flex clusters, which are a paid tier.

If the app matters to real users, this is the real fix. The pause is how the Free tier stays free.

How to keep a Free cluster active with a scheduled ping

The pause only triggers after 30 days of zero connections. So one real connection a day resets the clock with plenty of room to spare.

Make it a real connection from an app or script. The same forum thread warns that browsing collections in the Atlas UI or Compass may not count as activity.

One gotcha: Atlas only accepts connections from IP addresses on your project's access list. A scheduled job running somewhere new will be refused until you allow it.

Hand this prompt to your AI tool and it'll write a daily keep-alive that fails loudly:

Write a GitHub Actions workflow that keeps my MongoDB Atlas Free cluster from being auto-paused for inactivity.

Requirements:
- Runs once a day on a schedule, plus workflow_dispatch so I can run it by hand.
- Uses the official MongoDB Node.js driver and a connection string stored as a GitHub secret named MONGODB_URI (never hardcoded).
- Connects, runs a cheap { ping: 1 } command against the admin database, then closes the connection.
- Exits non-zero if the connection or ping fails, so a broken cluster shows up as a red run, not a silent green one.
- Add a top comment reminding me: (a) Atlas only accepts connections from IPs on my project's IP access list, and GitHub's runners don't have fixed IPs, so tell me my options and the security trade-off of each; (b) GitHub disables scheduled workflows in public repos after 60 days of no repo activity.

Give me the full workflow file, a package.json if needed, and exactly which secret to add.

How to know your MongoDB database is reachable before users do

A paused cluster doesn't announce itself. Your app just starts failing, and users notice first.

The fix is a health check: a tiny function that pings the database and reports the result somewhere that will shout when it goes wrong.

With Tell Me When Down, that's one call from your app. A ping command is MongoDB's cheapest "are you there?" question.

import { MongoClient } from "mongodb";
import { tmwd } from "@tellmewhendown/node";

const client = new MongoClient(process.env.MONGODB_URI);

export async function checkMongo() {
  const started = Date.now();
  try {
    await client.db("admin").command({ ping: 1 });
    await tmwd.check("db", { status: "ok", latencyMs: Date.now() - started });
  } catch (err) {
    await tmwd.check("db", { status: "fail", detail: { error: String(err) } });
  }
}

Run it on a schedule, from a cron route or a worker. Every run is also a real connection, so it doubles as your keep-alive.

If the check reports fail or goes quiet, you get an email. That covers a paused cluster and a keep-alive that silently stopped running.

The same idle-pause trap hits other free databases too. See why Supabase pauses your project, or the full cross-host playbook in how to keep a free backend awake.