MySQL and Slack: Replication Lag Threshold Alert Template

A scheduled Spojit workflow that watches your MySQL replica's lag and replication status and alerts Slack the moment a replica falls behind or stops, before stale reads reach your users.

What It Builds

A Schedule trigger fires every few minutes and a Connector node in Direct mode reads the replica's Seconds_Behind_Master, Slave_IO_Running, and Slave_SQL_Running fields from MySQL. A Condition node compares the lag against your threshold, and when the replica is behind or a replication thread has stopped, a Slack node posts a clear alert to your on-call channel.

The Prompt

Paste this into Miraxa and it builds the workflow, connecting the tools for you:

Build a workflow that runs every two minutes and queries my MySQL replica for its replication lag in seconds and whether both replication threads are running. If the lag is over 30 seconds, or either thread has stopped, post a message to the #db-oncall Slack channel with the replica name, the current lag, and which thread stopped.

Connectors Used

Schedule trigger - runs the check on a fixed cron interval in your timezone.
MySQL - reads replication lag and replica status fields from the replica.
Slack - posts the threshold alert to your chosen channel.

Customize It

Change the 30-second threshold to match your tolerance, swap #db-oncall for your team's channel, and adjust the two minutes interval to poll more or less often. You can also point the query at multiple replicas by naming each host in the prompt.

Tips

Use the MySQL connector in Direct mode so the status query runs the same way every time with no AI cost.
Grant the connection a read-only account with replication-status privileges; it never needs write access.
Keep the interval shorter than the lag you care about, so a stalled replica is caught before it drifts far.