DATA OPS
Reverse-ETL Row-Count Reconciliation Gate
After each reverse-ETL run, reconciles the row count Snowflake intended to sync against the count HubSpot actually accepted and emits a Datadog metric plus a Slack alert…
How it runs
The automated pipeline, trigger to output.
- TriggerSync-completion webhook fires from the reverse-ETL toolHTTP webhook
- ActionRead intended row count for the run from SnowflakeSnowflake
- ActionCount records actually updated in HubSpotHubSpot
- LogicCompute dropout percentage against tolerance
- ActionEmit the dropout delta as a Datadog metricDatadog
- OutputAlert Slack when dropout exceeds toleranceSlack
What it does
Reverse-ETL tools often report success even when a chunk of rows was silently dropped by the destination API (rate limits, validation rejects, dedupe). This workflow closes that gap. Triggered by a webhook the sync tool fires on completion, it reads how many records Snowflake queued for the destination, pulls how many HubSpot actually has updated in the run window, computes the dropout delta, and records it as a Datadog metric for trending. When the dropout exceeds your tolerance, it alerts Slack so the run can be re-driven.
When to use it
Use it when sync "success" is not enough and you need proof that the rows landed. Ideal for high-volume audiences where partial loads cause real damage.
How it works
- 1A webhook from the reverse-ETL tool fires when a sync run finishes.
- 2Snowflake query returns the intended row count for that run.
- 3HubSpot returns the count of records actually updated in the window.
- 4A logic step computes the dropout percentage against tolerance.
- 5The delta is emitted as a Datadog metric for dashboards and monitors.
- 6If tolerance is exceeded, Slack gets an alert with both counts and the run id.
Set it up
What you configure once, before turning it on.
- 1Connect SnowflakeWarehouses, queries, shares.
- 2Connect HubSpotCRM, deals, marketing, support.
- 3Connect DatadogMetrics, traces, log search.
- 4Connect SlackChannels, DMs, threads, mentions.
- 5Connect HTTP webhookTrigger any URL on agent actions.
- 6Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 7Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 8Test, 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.