Alert on New Rows in Trino with a Polling JDBC Trigger

Turn any Trino query into a monitor. The io.kestra.plugin.jdbc.trino.Trigger polls the cluster on a fixed interval and starts an execution only when the query returns at least one row, which makes it a natural fit for row-level alerting: failed payments, stuck orders, rejected records, anything expressible as a SELECT. This blueprint watches postgres.public.payments through Trino for payments that failed in the last five minutes and posts the count to Discord.

How it works

1. on_new_failed_payments (io.kestra.plugin.jdbc.trino.Trigger) runs the SELECT every five minutes (interval: PT5M). When zero rows match, no execution starts and nothing is logged as noise. When one or more rows match, an execution starts.
2. With fetchType: FETCH, the matching rows ride along on the trigger output as {{ trigger.rows }}, and {{ trigger.size }} carries the count as a plain scalar.
3. alert_failed_payments posts the count to Discord. Only the scalar trigger.size is interpolated into the JSON payload; the row list stays on the trigger output where downstream tasks can consume it safely.
4. The errors block posts a distinct Discord message when the flow itself fails, so a broken monitor is never mistaken for a quiet one.
5. The trigger ships disabled: true so importing the blueprint never polls a placeholder cluster.

What you get

• Near-real-time alerting on any condition you can write as SQL, without a streaming stack.
• Executions only when something is wrong; quiet windows leave no execution clutter.
• The offending rows attached to every alert execution for immediate triage.
• A monitor that also monitors itself through the error handler.

Who it's for

• Payments and revenue teams who need to know about failures within minutes, not at the daily batch.
• Data engineers adding operational alerting on top of an existing Trino deployment.
• On-call engineers who want the triggering rows attached to the alert, not just a count.

Why orchestrate this with Kestra

A cron script running the same SELECT would need its own state handling, deduplication of empty runs, alert delivery, failure reporting, and history. The JDBC trigger folds all of that into one declarative block: Kestra manages the polling loop, only materializes executions when rows match, exposes the rows and count as structured outputs, and records every firing in the execution history for audit.

Prerequisites

• A Trino cluster with a catalog exposing the table to watch, here postgres.public.payments with status and created_at columns.
• A polling window aligned with the trigger interval so rows are not missed or double-alerted; both are five minutes here.
• A Discord incoming webhook for alerts.

Secrets

• TRINO_URL: JDBC URL, e.g. jdbc:trino://host:443/postgres/public (use https on 443 in production; password authentication requires TLS).
• TRINO_USERNAME: Trino username.
• TRINO_PASSWORD: Trino password.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the four secrets to your Kestra namespace.
2. Point the trigger SQL at your table and adjust the failure condition and time window.
3. Set disabled: false on the trigger and insert a test row matching the condition.
4. Confirm the Discord alert arrives with the right count within one interval.

How to extend

• Switch the trigger to fetchType: STORE for large result sets; the rows then arrive as a file at {{ trigger.uri }}, ready for a downstream export or ticket attachment.
• Fan out per row with io.kestra.plugin.core.flow.Loop over {{ trigger.rows }} to open one ticket per failed payment.
• Add a second trigger with a different SQL condition to watch another table from the same flow logic.
• Route high-value failures differently by adding an If task on an amount threshold.

Links

• Trino plugin documentation
• Trino documentation