Data & analytics

Data monitors

Standing checks on your tables, run on the platform's own clock, with the history to know what normal looks like, an incident opened when a check fails and closed when it passes again, and a notification either way.

What it is#

The catalog notices schema drift when it crawls and ETL gates quality on the way in. Nothing watched a table that was simply standing there: going stale, shrinking, filling with nulls, growing duplicates. That is how a dashboard shows last week's number with today's date on it. A monitor is the standing question; an incident is the open answer. Find them under Data & BI → Data monitors.

What a monitor checks#

Check	Asks	Alerts when
Freshness	The newest value of a timestamp column.	It is older than the limit you set, or the column is empty.
Volume	The row count, and the rows added since the last run.	The total is outside your bounds, or the judged value is unusual against the last runs.
Schema	The column names and types: the lakehouse catalog listing, or information_schema on a warehouse.	A column was added, removed or retyped since the last run; the first run records the baseline.
Null rate	The share of nulls in a column.	It is above the limit you set.
Uniqueness	Duplicate combinations of the columns you name.	There is at least one.
Custom SQL	A SELECT of your own returning one number: negative amounts, orphaned keys, a ratio.	It is outside the minimum and maximum you set.

Tables can live in the lakehouse (pick a table; columns are offered) or in a connected warehouse you own (pick the connection, type the schema and table). A lakehouse check runs through the same governed chokepoint as every other lakehouse read, audited as a data read and stamped with the snapshot it saw.

Baselines#

Volume is the check where "normal" is not a number you know in advance. A volume monitor keeps the value it judges from each run — rows added since the last run for an append-only table, the total for a table that is replaced — and, once it has five, alerts when a new value is further from the mean than three standard deviations. A history with no spread at all treats any change as unusual, because that is what the history says; a tiny spread is floored so one-row jitter never pages anyone. Bounds you set apply first and always.

Schedules and incidents#

Schedules. Hourly, daily, weekly or a cron expression, on the scheduler sweep the ETL pipelines and ML schedules share, claimed by clock so several replicas never run one monitor twice. Run now runs a check on demand; creating a monitor runs it once by default.
Incidents. The first failing run opens one and notifies you, in-app and on any connected channel (Slack, Teams, a webhook). Further failing runs extend it and count occurrences without notifying again. The first passing run resolves it and notifies "Recovered". Acknowledge marks it seen; Resolve closes it by hand.
Errors are not findings. A check that cannot answer — a timeout, a dropped table, a query error — is recorded as an error and opens no incident.

Agents#

An agent with the Data health tool turned on can answer "is the revenue table fresh?" from the monitors and open incidents of the person it runs as, on scheduled and headless runs too, because the tool re-derives what it may read from the run's owner.

Governance#

Ownership. A monitor belongs to the person who created it and reads the table as that person; a warehouse monitor needs a connection you own.
Audit. The table's trigger audits every change to a definition; the runner audits data.monitor.alert when an incident opens and data.incident.resolved when a run closes one; a person acknowledging or resolving audits data.incident.acknowledged / data.incident.resolved.
Limits. DATA_MONITORS_PER_SWEEP (20) is how many due monitors one sweep runs and DATA_MONITOR_ANOMALY_SIGMA (3) the baseline threshold; both are editable under Admin → Developer runtime. A check must answer within 60 seconds.

How this compares

Monte Carlo, Anomalo and Metaplane sell this as a product: freshness, volume, schema and custom checks with learned baselines and incidents. This is the same shape, on the tables the platform already governs, alerting through the channels it already has, and readable by its agents. Not yet: column-level lineage from an incident to the dashboards it affects, and checks inside a pipeline before its load commits (the ETL quality gates cover that half).

Troubleshooting#

Symptom	Cause and fix
"The check failed" with a column name	The column was renamed or dropped; edit the monitor. A schema monitor on the same table would have said so.
Volume never alerts on anomaly	It needs five runs of history first; set bounds for the meantime.
Freshness alerts on a table loaded nightly	Set the limit above the load interval, or schedule the check after the load.
No notification arrived	Incidents notify once when opened and once when resolved; a still-failing monitor extends the incident silently.

PreviousWorkflows Next AI in SQL