# Alert Slack when PlanetScale database changes stall

> Checks your PlanetScale database changes every hour on weekdays and posts one Slack alert when something is stuck, errored, or waiting on approval.

- Workflow type: agent
- Services: PlanetScale, Slack Bot
- Categories: Engineering
- Published: 2026-08-09

## What it does

- Checks every hour on weekdays for database changes waiting to go live across all of your databases
- Flags three problems: changes open more than 24 hours with nobody approving, changes that hit an error, and changes stuck in line waiting to be applied
- Posts a single grouped Slack message naming the database, the branch, how long it has been waiting, and who still owes an approval
- Adds a plain language sentence explaining what each pending change actually does, and stays completely silent when everything is healthy

## What you'll need

- A PlanetScale account with access to the databases you want watched
- The name of your PlanetScale organization
- A Slack workspace and a channel where engineering alerts should land

## Prompt

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.

## How to customize

- Change the 24 hour no-approval threshold to match how quickly your team normally reviews changes
- Point the alert at a different Slack channel, or run separate copies per team or per database
- Adjust the schedule, which runs hourly on weekdays by default, or narrow it to only your production databases

## FAQ

### Will this ever apply or undo a database change on its own?

No. It only looks and reports. It will never push a change live, approve one, or roll one back, even if something looks obviously ready or obviously broken. A person always decides what happens next.

### What happens when nothing is wrong?

Nothing at all. It sends no message. That is deliberate, because an hourly all-clear post would train everyone to ignore the channel, and then the real alerts get missed too.

### Does it check all of our databases or just one?

All of them. It looks up every database in your organization and checks each one, so a change sitting on a less-watched database still gets caught.

### Can I change how long something waits before it gets flagged?

Yes. The 24 hour mark is just a starting point, and so is the how-long-in-line threshold. Both are set up as simple settings you can edit if your team moves faster or slower.

### Will it keep alerting about the same stuck change every hour?

While a change still meets the criteria it will keep appearing in the hourly message, which is usually what you want for something genuinely stuck. If that feels repetitive you can widen the schedule to a few times a day.

Use this prompt in General Input: https://www.generalinput.com/prompts/alert-slack-when-planetscale-database-changes-stall