Skip to main content
A deployment rule selects a set of assets and places the same monitors on all of them. You can select assets by data source, data product, type, tags or a query. The rule keeps the selection up to date: an asset that starts to match later gets the monitors too. You change the sensitivity or severity of all those monitors in one place, and you can exclude assets with exclusion rules.

​
Setting Up Deployment Rules

  • Navigate to Deployment Rules under Health Deployment Rule Setup
  • Click Add deployment rule
  • Under Settings, choose the Metrics (table stats metrics), the Sensitivity (read more) and the Severity
  • If the data skips some days of the week on purpose, turn on Use a weekly delay pattern (read more). This option is in beta. If you do not see it, ask support to enable it for your workspace.
  • Under Tables, select the assets you want to monitor with the Visual builder or a ResolverQL query Deployment Rule Setup
Do not apply rules too broadly, as too many alerts lead to noise. Use exclusions and overrides to refine rule coverage.
  • To keep specific assets out of all rules, add an exclusion rule under Exclusion rules on the Deployment rules page.

​
Changing a deployment rule

On the Deployment rules page you can:
  • Edit a rule to add or remove assets.
  • Change the sensitivity if you get too many or too few alerts.
  • Delete a rule that no longer applies.

​
What a rule deploys

A deployment rule pairs a selection with one of two payloads:
  • table_stats: the table stats metrics covered above, deployed onto every asset the selection matches.
  • sql_tests: the SQL tests listed under the rule’s own tests:, deployed onto every table or view the selection matches. In the app, these are under SQL test rules.
Both kinds live in the same deployment_rules: list of a monitors-as-code configuration:
Every field, with its type and validation rules, is in the configuration reference; the commands that deploy a configuration are in the CLI reference. The rest of this section is what a sql_tests rule does once it is deployed.

​
Only the tables that carry the columns

A test is deployed onto a matched table only if that table has every column the test reads: the columns it checks, any select_columns, the time_partition_column of a unique or relationships test, and for relationships the columns on the referenced table as well. A table that is missing one of them gets no test, and the deploy plan shows the test as skipped. So a broad selection is safe. A test is skipped as a whole. A not_null on [email, account_id] is skipped on a table that has only email. It is not reduced to email alone, because unique(a, b) checks something different from unique(a). If you want a check per column, declare one test per column. A business_rule is gated on its select_columns alone: its SQL expression is never parsed, so a rule whose expression reads status without declaring it deploys anyway, while one that declares select_columns: [status] is skipped on every table without that column. A business_query declares no columns of its own and is never gated. If the schema of a matched table has not been ingested yet, the table keeps the tests it already has, and the rule tries again on the next sync. New tests for that table wait until its columns are known.

​
When a table leaves the selection

The tests a rule deployed onto a table are deleted once that table stops matching. Set keep_removed_tests: true to leave them in place instead. The rule then stops resyncing those tests altogether, and they are yours to remove if they start failing. If a table still matches the rule but loses a column that a test reads, that test is deleted on the next sync. keep_removed_tests does not apply here. It only applies when a table leaves the selection.

​
Deleting a rule deletes the tests it deployed

Editing a rule’s selection resyncs it. Tests appear on the tables the edited selection matches, go away from the tables it stops matching, and tables matched both before and after keep the tests they already had. Deleting a sql_tests rule deletes every test the rule deployed, together with those tests’ check entities and their history. Nothing brings them back. A rule is identified by its id: if it has one, and otherwise by its name within its namespace. So renaming a rule that has no id: replaces it. The old rule is deleted with everything it deployed, and the next scheduled sync creates the tests again under the new name, without their history. Give a rule an id: before you rename it, and the rename is an update.

​
A relationships test names one reference table

A relationships test under a rule names one reference table per references[] entry, and every matched table is checked against that same table. For example, many tables with customer_id are checked against one dim.customers. The reference is not resolved per match, so a rule cannot express “each staging.X against its own raw.X”. Write those tests one per table, under the entity they belong to. The reference table has to sit in the same integration as the matched tables, because the test runs on the matched table’s connection. Nothing narrows the selection to that integration for you, so confine it yourself with with_integration_ids(...). A match in another integration gets a test whose reference resolves on the wrong connection: it fails every run, or it joins a table that happens to share the name. A referenced table that has not been ingested leaves the test waiting indefinitely, and the deploy plan says so, naming the table.

​
Best Practices for Deployment Rules

See Monitors overview for best practices when setting up monitors. Specifically for deployment rules, we recommend you consider:
  • Use exclusions to reduce noise. Exclude temporary tables, and datasets where large changes are normal.
  • Use overrides to change the sensitivity for some assets. For example, use precise on financial data to catch small anomalies, and relaxed on less important data to hear only about large ones.

​
Managing deployment rules programmatically

A rule’s selection, metrics, sensitivity and exclusions can be read, previewed and deployed outside the app.
  • Public API: synq.monitors.automated_monitors.v1.DeploymentRulesService. Every method on it, reads included, needs a token with SCOPE_MONITORS_AUTOMATIC_EDIT. See the API reference and API scopes.
  • MCP: the deployment rule tools let an AI assistant author a selection, see exactly which monitors a rule would create, keep and delete before anything happens, and deploy it once you approve. Previewing changes nothing, so you can also use it to check the selection query. Deploying and deleting ask for confirmation and need the Deploy permission.