New to Kestra?
Use blueprints to kickstart your first workflows.
Monitor PostgreSQL lock contention and blocking transactions with Kestra. Inspect pg_locks, detect cascading wait trees, and alert DBAs via Slack.
In production PostgreSQL environments, slow queries rarely take down an application on their own, but cascading lock conflicts do. When an uncommitted transaction, slow migration, or unindexed update acquires an exclusive lock on a hot table, dozens of incoming requests queue up behind it. Within minutes, connection pools saturate, application threads starve, and the web tier throws 504 Gateway Timeouts.
This blueprint introspects PostgreSQL's native pg_locks and pg_stat_activity system catalogs to identify root blocking sessions, the queries they are running, their application origins, and how long downstream queries have been waiting. If lock wait times exceed your threshold, it sends an actionable Slack alert with the exact PID and copy-paste remediation commands.
query_blocking_locks (io.kestra.plugin.jdbc.postgresql.Query) connects to the target database and runs a self-join query against pg_locks and pg_stat_activity with fetchType: FETCH. It isolates granted locks that are blocking ungranted lock requests where wait duration exceeds inputs.min_wait_seconds.emit_lock_metrics (io.kestra.plugin.core.output.OutputValues) exports diagnostic variables (blocked_transactions_count, database_scanned, host_scanned, audited_at) into execution outputs.evaluate_lock_contention (io.kestra.plugin.core.flow.If) evaluates whether any blocking conflicts were found:notify_dba_slack (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) dispatches a formatted Slack notification detailing blocker PIDs, application names, client IPs, wait durations, and SQL snippets.log_healthy_locks (io.kestra.plugin.core.log.Log) logs an all-clear confirmation.alert_on_failure in the errors block dispatches a Slack alert if database connectivity fails.idle in transaction).SELECT pg_cancel_backend(...)) delivered directly to Slack.Ad-hoc manual inspections in psql only happen after an incident is already underway, and shell scripts on cron lack execution lineage, centralized secrets, and reliable error alerts. Kestra provides native JDBC connectivity, secure credential handling, dual schedule and webhook triggers, and automated notification routing without external agents or daemons.
pg_stat_activity and pg_locks.POSTGRES_USER: Database username with read access to system catalogs.POSTGRES_PASSWORD: Database password for authentication.SLACK_WEBHOOK_URL: Slack Incoming Webhook destination URL.WEBHOOK_KEY: Secret authentication key for the manual webhook trigger.POSTGRES_USER, POSTGRES_PASSWORD, SLACK_WEBHOOK_URL, and WEBHOOK_KEY in your Kestra namespace secrets.postgres_host, postgres_port, and database_name inputs to match your database environment.scheduled_monitor trigger to run automated checks every 10 minutes.