Monitor MySQL DELETE events in real time with Debezium and send Slack alerts

Watch a MySQL table for deletions as they happen and get notified in seconds. This blueprint uses Debezium change data capture (CDC) to stream binlog events from MySQL into Kestra in real time, filters for DELETE operations, and sends a Slack alert the moment a row is removed. It solves the gap that polling and scheduled queries leave open: instead of asking the database "what changed since last time" on a fixed interval, the flow reacts to each committed transaction the instant it lands in the binlog, with no missed events and no batch lag.

How it works

• The io.kestra.plugin.debezium.mysql.RealtimeTrigger trigger subscribes directly to the MySQL binary log for the test.employees table, using snapshotMode: NEVER so it streams only new changes and emits one execution per CDC event.
• Each INSERT, UPDATE, or DELETE event arrives as a structured payload exposed to the flow as trigger.data, including the row column values (first_name, last_name) and the CDC metadata.
• The io.kestra.plugin.core.flow.If task evaluates trigger.data.metadata.operation == 'DELETE' and only runs its branch for deletions.
• Inside that branch, io.kestra.plugin.core.log.Log records which employee was removed, and io.kestra.plugin.slack.notifications.SlackExecution posts a real-time alert to a Slack webhook.

What you get

• Sub-second reaction to row deletions, driven by binlog events rather than polling.
• A clean, code-free CDC pipeline: Debezium parses the binlog and hands you typed fields directly.
• Targeted alerting that ignores inserts and updates and only escalates destructive operations.
• One Kestra execution per change event, giving you a full audit trail in the UI.

Who it's for

• Data engineers building real-time CDC pipelines and replication-aware workflows.
• Platform and SRE teams that need instant visibility into destructive database operations.
• Compliance and security owners tracking deletions of sensitive records.

Why orchestrate this with Kestra

Debezium can stream binlog changes, but it does not orchestrate what happens next. Kestra turns each CDC event into a governed execution: the RealtimeTrigger is event driven (no cron, no polling window to tune), every event becomes a versioned run with full lineage and logs, and you get built-in retries, conditional branching, and failure handling around the downstream Slack call. The whole pipeline is declared in one readable YAML file, version controlled and reviewable, instead of glued together with standalone consumer scripts that a database scheduler could never coordinate.

Prerequisites

• A MySQL instance reachable from your Kestra workers, started with binary logging enabled and a unique server-id (the flow uses serverId: 12345 on port 13306).
• Replication privileges granted to the connecting user, and a test.employees table to monitor.
• The Kestra Debezium and Slack plugins available in your instance.

Secrets

• SLACK_WEBHOOK: the Slack incoming webhook URL used by the SlackExecution task to post the deletion alert.

Quick start

1. Start a MySQL container with binlog enabled, for example: docker run -d --name mysql -p 13306:3306 -e MYSQL_ROOT_PASSWORD=root mysql mysqld --server-id=12345 --log-bin=/var/lib/mysql/mysql-bin.log --binlog_do_db=test
2. Grant replication access and confirm binlog is on: GRANT REPLICATION SLAVE ON *.* TO 'root'@'%'; then SHOW VARIABLES LIKE 'log_bin';
3. Create the monitored table: CREATE DATABASE test; and CREATE TABLE test.employees (id INT, first_name VARCHAR(25), last_name VARCHAR(25), city VARCHAR(25));
4. Add the SLACK_WEBHOOK secret in Kestra, then update the trigger hostname, port, username, and password to match your MySQL instance.
5. Deploy the flow and delete a row from test.employees to receive an instant Slack alert.

How to extend

• Add branches to the If task to act on CREATE and UPDATE operations, not just DELETE.
• Swap or add downstream tasks: write the event to a data warehouse, append to an audit log table, or page an on-call tool.
• Widen includedTables to capture multiple tables, or point the trigger at a production schema.
• Enrich the alert with more columns from trigger.data, or route different severities to different Slack channels.

Links

• Debezium plugin docs: https://kestra.io/plugins/plugin-debezium
• Slack plugin docs: https://kestra.io/plugins/plugin-notifications