Checks from pipelines

Schedule checks to run after the pipeline

The most common pattern: schedule the check to run a few minutes after your pipeline's known completion time — for example, if a nightly dbt run finishes by 2:00 AM, schedule the checks that depend on it for 2:15 AM. Combine this with an alert rule so your team is notified the moment a scheduled check fails, rather than needing to poll the Results screen.

This is the right fit for most "did last night's load look right" needs, and does not require the pipeline itself to know anything about CatalystData.

Keep checks versioned with your pipeline

Even though checks are added through the UI, drafting them as YAML in the same repository as your pipeline or dbt project — next to the models they cover — keeps them reviewed and versioned alongside the code that produces the data, and means a new table added to the pipeline gets its checks proposed in the same pull request.

Failing the pipeline itself on a check failure

Some teams want the pipeline run to fail synchronously when a check fails — a quality gate before a promotion, or before dbt build is considered successful. That's not available today: it would require calling CatalystData directly to trigger a run and read back the result, and that isn't offered yet. If your pipeline needs a synchronous quality gate rather than a scheduled check with an alert, talk to your CatalystData contact — it's useful to know there's demand for it.