Catch MongoDB Atlas clusters with stale backups every morning

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.