DATA OPS
Operational Postgres Source Drift Watcher
Monitors application Postgres tables that feed the warehouse, detects when a source schema changes ahead of its Snowflake ingest contract.
How it runs
The automated pipeline, trigger to output.
- TriggerScheduled source check
- ActionRead table definitions from operational PostgresPostgres
- ActionRead agreed landing contract from SnowflakeSnowflake
- LogicDiff source vs contract; flag unprepared columns
- OutputOpen Linear ticket and post Slack heads-upLinear
What it does
Schema drift usually starts upstream, in the operational database, before it ever reaches the warehouse. This workflow watches the application Postgres tables that feed ingestion, compares their current shape to the agreed Snowflake landing contract, and raises an alert the instant the source moves ahead of the contract — giving the warehouse team lead time before ingestion breaks.
When to use it
Use it when product engineers ship migrations that silently change the tables your ETL reads. Catching the change at the source, not after a failed load, prevents broken pipelines and dropped rows.
How it works
- 1A schedule starts the source check.
- 2Read current table definitions from the operational Postgres database.
- 3Read the agreed landing contract registered in Snowflake.
- 4Diff source against contract and flag any column the warehouse is not prepared to receive.
- 5If drift is found, open a Linear ticket for the data team and post a Slack heads-up to the owning service team.
Set it up
What you configure once, before turning it on.
- 1Connect PostgresAny Postgres URL — query, write, migrate.
- 2Connect SnowflakeWarehouses, queries, shares.
- 3Connect LinearIssues, projects, cycles, triage.
- 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.
