Checkpoints (retired)
Checkpoints have been replaced by validations. A validation bundles the rules of one or more data assets, runs them together, keeps a health score, and carries its own schedules. Old
/checkpointslinks in the app open the Validations page. This page stays so older links keep working.
Where things moved
| You used to… | Now you… |
|---|---|
| Create a checkpoint for an asset and a suite | Add rules to the asset — every asset with rules has a default validation that holds all of them. To bundle several assets, create a validation. See Create and run a validation. |
| Click Run now on a checkpoint | Click ▶ Run on the validation, or on the asset itself. An asset's Run runs its default validation; a single rule's Run runs just that rule. See Execution runs → Asset and rule runs. |
| Add a schedule to a checkpoint | Use the validation's Schedule card — see Schedule a validation. A checkpoint schedule nobody edited keeps firing, and now runs the validation its checkpoint maps to. |
| Read a checkpoint's results | Open the validation's Execution runs, or filter Results by validation or asset. See Execution runs. |
| Alert on a checkpoint's failures | Scope an alert rule to one or more validations. |
Tag a checkpoint dbt:<schema>.<model> for the dbt Cloud webhook or the GitHub Action | Tag the validation instead. See Block pull requests on data quality. |
What happened to your history
Nothing was lost. Every checkpoint maps to a validation: the asset's default validation, or the validation the checkpoint was upgraded into. Past checkpoint runs:
- stay readable on the Results page, labelled as asset runs;
- are also filed as execution runs (trigger
asset) under the validation their checkpoint maps to, so they appear in that validation's Execution runs card and count toward its 30-day health score.
For API and integration users
The checkpoint endpoints are a deprecated alias for one release, so existing pipelines keep running while you move them to validations. The alias is removed in the next major SDK release.
| Call | What it does now |
|---|---|
GET /api/v1/organizations/{org_id}/workspaces/{ws_id}/checkpoints and GET .../checkpoints/{id} | Returns the legacy checkpoint rows, each with validation_id (the validation it maps to) and deprecated: true. |
POST .../checkpoints/{id}/run | Runs the mapped validation. Returns {validation_id, parent_result_id, execution_run_id, run_queue_id: null, deprecated: true}. Poll the execution run with execution_run_id. |
POST .../checkpoints/{id}/run-subset | Runs the mapped validation once per partition value. |
POST .../checkpoints/{id}/schedules | Creates a schedule for the mapped validation. |
POST, PATCH or DELETE on .../checkpoints[/{id}] | 410 Gone: checkpoints can no longer be created, edited, or deleted. |
Every alias response carries a Deprecation: true header and a Link: <…/validations>; rel="successor-version" header pointing at the validations endpoint. A checkpoint that maps to no validation returns 409 on run. Per-run rule_parameters overrides are no longer supported: a run with a non-empty rule_parameters returns 422, because validations carry their own rule settings.
New integrations run validations directly:
POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/validations/{validation_id}/run
To run one asset, or one rule, the way a checkpoint's Run now used to:
POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/data-assets/{asset_id}/rules/run
POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/data-assets/{asset_id}/rules/{rule_id}/run
Both run the asset's default validation (the second restricted to that rule) and return an execution_run_id to poll. The SDKs (client.validations, client.execution_runs), the Airflow provider (ValidationOperator, ExecutionRunSensor), the Dagster provider (dq_cloud_check(validation_id=...)), and the MCP server (mc_validation_*, mc_execution_run_*) all have validation-based equivalents; their checkpoint helpers are deprecated shims over the alias. See Execution runs → API and the API reference.