DATA OPS
dbt Run Failure Owner Pager
Receives dbt run-result webhooks, identifies which models failed and who owns them, and pages the on-call data engineer through PagerDuty only when a model tagged critical breaks.
How it runs
The automated pipeline, trigger to output.
- Triggerdbt run-results webhookHTTP webhook
- LogicFilter to failed models
- ActionLook up owner and criticality in PostgresPostgres
- LogicBranch on critical vs non-critical
- ActionOpen PagerDuty incident for criticalPagerDuty
- OutputPost non-critical failures to SlackSlack
What it does
Listens for dbt run-result payloads at the end of every orchestration run. It parses the per-model results, isolates failures, looks up each failed model's owner and criticality tag, and escalates to PagerDuty for critical-tagged failures while logging non-critical failures to Slack. The page includes the model name, error message, and the run URL.
When to use it
When your dbt jobs run on a schedule and a failed model can poison every dashboard built on it, but you don't want every flaky non-critical model waking up on-call. Use it to route severity correctly: critical breaks page, everything else gets a daytime ping.
How it works
- 1A webhook receives the dbt run-results payload when a run completes.
- 2A logic step filters the node results down to status = error or fail.
- 3The flow joins each failed model to its owner and criticality from a Postgres ownership table.
- 4A branch routes critical failures to PagerDuty as an incident and non-critical failures to a Slack channel.
- 5The PagerDuty incident carries the model name, compiled error, and direct run link for fast triage.
Set it up
What you configure once, before turning it on.
- 1Connect HTTP webhookTrigger any URL on agent actions.
- 2Connect PostgresAny Postgres URL — query, write, migrate.
- 3Connect PagerDutyIncidents, on-call, escalations.
- 4Connect SlackChannels, DMs, threads, mentions.
- 5Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 6Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 7Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More Data Ops workflows
Snowflake column type-drift sentinel with Linear fix ticket
Snapshots the data types of every column in your tracked Snowflake schemas on a schedule, diffs against the last snapshot.
Daily BigQuery Scheduled-Query Cost Attribution to Owners
Each morning, totals the prior day's on-demand bytes-billed per scheduled query, maps each query to its owner from a label, and posts a per-owner cost leaderboard to Slack.
BigQuery dropped/renamed column sentinel with PagerDuty incident
Detects when a column is dropped or renamed in your governed BigQuery datasets and, because that breaks downstream queries hard, pages the on-call via PagerDuty and posts…
PR-time Snowflake schema contract check on dbt model changes
When a pull request changes a dbt model, it compares the model's declared output columns against the live Snowflake table it will replace and blocks the merge with a GitHub check…
Agent-triaged warehouse drift with impact analysis and runbook update
On a webhook from your warehouse audit log, an agent investigates the changed column, traces which downstream models and dashboards depend on it.
Cross-warehouse replication schema mismatch reconciler
Compares the column shape of mirrored tables between BigQuery and Snowflake and, when a replicated table has drifted out of sync between the two, opens an Asana task for the data…
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.