# Catch MongoDB Atlas clusters with stale backups every morning

> Every day at 6am, check when each database cluster was last backed up and post a worst first list to your ops channel.

- Workflow type: code
- Services: MongoDB Atlas, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-07

## What it does

- Checks every database cluster in your MongoDB Atlas account each morning and finds the most recent completed backup for each one.
- Compares each cluster's newest backup against your recovery target, 24 hours by default, and marks it pass or fail.
- Posts a single Slack message with a table of every cluster, how many hours old its backup is, and its status, sorted so failures sit at the top.
- Counts a cluster with backups switched off or no backups at all as a failure, so nothing quietly slips through.

## What you'll need

- A MongoDB Atlas account with access to the projects and clusters you want checked.
- A Slack workspace and a channel for the alerts, such as #platform-ops.
- A rough idea of how fresh your backups need to be, for example within the last 24 hours.

## Prompt

Every day at 6am, check that every MongoDB Atlas cluster we run has a recent backup, and post the result to Slack so we find out the same morning when one falls behind.

Start with List Projects in MongoDB Atlas to get every project the API key can access, then call List Clusters for each project, then call List Cloud Backup Snapshots for each cluster. For each cluster, take the most recent snapshot with a completed status. Ignore snapshots that are still queued, in progress, or failed, because a snapshot that has not finished is not a usable restore point. Page through the Atlas list responses rather than reading only the first page, so large estates are fully covered.

Work out how old that newest completed snapshot is in hours relative to the start of the run, and compare it against our recovery point objective, which is 24 hours by default. An age at or under the objective is a pass. Anything older is a fail.

Treat a cluster that has cloud backup disabled, or that returns no snapshots at all, as a fail rather than skipping it. Those are the most dangerous cases, so sort them above clusters that merely have a stale snapshot, and label them clearly with something like 'backups disabled' or 'no snapshots' in place of an hour count.

Skip any cluster whose name starts with dev- or test- so we only page on production.

Expose the recovery point objective in hours (default 24), the skipped name prefixes (default dev- and test-), and the target Slack channel (default #platform-ops) as inputs that are easy to edit without touching the logic.

Post exactly one message per run to #platform-ops using the Slack Bot Send a Message action, never one message per cluster. Open with a single line counting how many checked clusters failed, then include a table with a row for each checked cluster showing the project name, the cluster name, the age of its newest completed snapshot in hours, and a pass or fail status. Sort worst first so every failure sits at the top of the table.

If every checked cluster passes, skip the table completely and post a short all clear line instead, such as 'All 11 production clusters have a backup within 24 hours.'

This workflow only reads from MongoDB Atlas. It never takes a snapshot, edits a backup policy, or changes a cluster, so there is no asynchronous work to poll for completion.

## How to customize

- Change the schedule: run it at 6am, twice a day, or every few hours if your recovery target is tighter.
- Set your own freshness target: swap 24 hours for 6, 12, or whatever your team has promised the business.
- Decide what gets checked and where it lands: skip clusters by name prefix, such as dev- and test-, and point the message at any channel.

## Example output

2 of 11 production clusters are outside the 24 hour backup target.

Project      | Cluster          | Latest backup   | Status
Payments     | prod-billing     | backups disabled | FAIL
Analytics    | prod-warehouse   | 41h             | FAIL
Core         | prod-api         | 9h              | PASS
Core         | prod-sessions    | 7h              | PASS
Analytics    | prod-events      | 4h              | PASS

## FAQ

### Will this change anything in my databases?

No. It only reads backup information. It never creates, deletes, or restores a backup, and it does not touch your clusters or the data inside them.

### What happens if a cluster has backups turned off?

It is reported as a failure and sorted to the very top of the list rather than being skipped. A cluster with no backup at all is the most important thing for you to see.

### Do I get a message even when everything is fine?

Yes, but a short one. If every cluster passes, you get a single all clear line instead of the full table, so the channel stays quiet on good days.

### Can I stop it alerting on my development clusters?

Yes. Any cluster whose name starts with dev- or test- is skipped by default, and you can edit that list to match your own naming convention.

### Does this work if I have several Atlas projects?

Yes. It walks every project your account can see and checks the clusters in each one, so you get your whole estate in a single message.

Use this prompt in General Input: https://www.generalinput.com/prompts/catch-mongodb-atlas-clusters-with-stale-backups-every-morning