Alert Slack when PlanetScale database changes stall

Every hour on weekdays, check our PlanetScale deploy requests and tell us in Slack when a schema migration is stalling, so that nothing sits waiting silently.

Start by listing the PlanetScale databases in our organization so the check covers all of them rather than a hardcoded few. For each database, list its deploy requests and keep the ones that are still open. Also get the deploy queue for each database, so you can see what is currently lined up to be applied and how long it has been sitting there.

For every open deploy request, get the deploy request detail and list its reviews. The detail gives you the branch, the deploy request number, when it was opened, its current state, and the schema changes it contains. Remember that deploy requests are addressed by number rather than by id. The reviews tell you who has looked at it and whether anyone actually approved it, as opposed to just commenting.

Flag a deploy request when any of these three things is true. First, it has been open for more than 24 hours and has no approving review. Second, it is in an errored state. Third, it has been sitting in the deploy queue longer than expected, which by default means more than 30 minutes without progressing.

If anything is flagged, post one grouped message to our engineering Slack channel. Do not send a separate message per deploy request. Group the findings under three headings, waiting on review, errored, and stuck in the queue. For each item, name the database, the branch, the deploy request number, how long it has been waiting in plain terms such as 3 days or 6 hours, and who still owes a review. If nobody has been requested as a reviewer, say that plainly rather than guessing at a name.

For each flagged deploy request, add one short plain language sentence describing what the schema change actually does, for example adding a nullable column to a table, dropping an index, or widening a column type. Base this on the deploy request detail rather than speculating, and if the change is unclear say so instead of inventing a description. The goal is that someone skimming the channel understands the risk without opening PlanetScale.

If nothing meets the criteria, do nothing at all and send no Slack message. A quiet channel is the correct output for a healthy hour. Posting an all clear message every hour would make the alert easy to tune out, which defeats the point.

This workflow is strictly read only against PlanetScale. Never queue a deploy request, never complete a gated deploy request, and never revert one, even if a deploy request looks obviously ready or obviously broken, and even if a revert window is about to close. Reporting is the entire job and a human decides what to do next.

Keep the 24 hour review threshold, the deploy queue threshold, the target Slack channel, and the PlanetScale organization name as clearly labelled settings at the top of the workflow, since we will want to tune them without rewriting the logic.