Clean up Upstash preview databases after pull requests close

Every night at 2am, sweep my Upstash account for preview and pull request Redis databases that outlived the branch they were created for. Forgotten preview databases are a silent cost leak, because Upstash bills storage per GB-month plus per command, so an orphaned database keeps charging me long after its branch is gone. Safety is the point of this workflow: it should always be far more willing to leave a database alone than to delete one.

Start with the Upstash List Redis Databases operation to pull every database in the account. Select only databases whose name matches my preview naming convention, meaning a pr- or preview- prefix carrying the pull request number, for example pr-1234-checkout or preview-1234. Treat this prefix list as a strict allowlist. Any database whose name does not start with one of those prefixes is out of scope completely: do not resolve it, do not treat it as a candidate, and never delete it under any circumstance. Production, staging, and everything else must go untouched. It is fine to report how many databases were ignored for not matching, but do not list them individually.

For each database that does match, parse the pull request number out of the name and resolve the corresponding pull request in GitHub. Use List Pull Requests, filtering by state so that open, closed, and merged pull requests are all visible, or Search Issues and Pull Requests with query qualifiers when the repository is not obvious from the database name. Use Get a Pull Request to read the merge status and the exact time the pull request was closed. Also call the Upstash Get Redis Database Stats operation for every candidate, so the report can show what each stale database is costing per month.

Delete a database with the Upstash Delete Redis Database operation only when every one of these conditions holds: the database name matched the preview prefix allowlist, the pull request was confidently resolved to exactly one pull request, that pull request is closed or merged, and it has been closed for at least three full days. The three day grace period is deliberate. Do not delete the instant a pull request merges, because people reopen pull requests and re-run previews shortly afterwards. A nightly sweep also catches databases whose pull request closed long before this workflow existed.

If a pull request cannot be confidently resolved, skip the database and leave it in place. Ambiguity always means skip, never delete. That covers a name with no parseable pull request number, a number that matches no pull request, a number that matches more than one pull request with no reliable way to tell which is correct, and any case where the GitHub lookup fails or errors. Every skipped database must appear in the summary with the specific reason it was skipped, so I can either fix the naming or remove it by hand.

The very first execution must be report only and must delete nothing, whatever it finds. I want to confirm that the naming convention actually matches my databases before anything is removed. That first summary should state plainly that it was a dry run and list exactly what it would have deleted. Once I have confirmed that report, deletion can be turned on for later runs.

Finish every run by posting a summary with the Slack Bot Send a Message operation. Show what was deleted, naming each database and its pull request, the estimated monthly saving for each one and the total saved across the sweep, and then every candidate database it deliberately left alone together with the reason, such as the pull request still being open, the database sitting inside the three day grace period, or the pull request not being resolvable. Post the summary even when nothing qualified for deletion, so I know the sweep ran.