Glossary of Terminologies

A page of monitor terminologies used in the Data Quality V2 guides.

Monitors

• Aggregate monitor — a monitor that produces a single computed value per run (for example, the data's age, a row count, or an average). Evaluated with a threshold, never a tolerance.

• Case — a group of related incidents, used for triage and resolution. A case stays open until someone closes it; any new incidents after closure start a new case.

• Custom attribute — a user-defined tag or key/value pair on a monitor (for example, severity, domain, or owning team), also visible on the incidents and cases it produces, and usable to route alerts.

• Destructive change — a configuration change significant enough that it creates a brand-new version of the monitor rather than editing the existing one in place, so run history isn't blended across two different definitions of "pass."

• Detection Method — how a Freshness or Volume monitor figures out when data last changed, or how many rows exist: either by asking the data source's own metadata, or by reading a specific timestamp column you select.

• DQ dimension — a label (Accuracy, Completeness, Uniqueness, Validity, Timeliness, Consistency, Granularity, or Others) assigned to a monitor to categorize which aspect of data quality its score contributes to, for reporting purposes only.

• Incident — created automatically when a monitor's evaluation fails. Carries full context about what failed and why.

• Row-level monitor — a monitor that checks every individual row and counts how many fail. Evaluated with a tolerance, never a threshold.

• Scan Method — how much of a table a Field Health monitor reads each run: the whole table (Full Table Scan) or only the newly arrived slice (Incremental Scan).

• Scheduled time vs. actual run time — a monitor is scheduled to run at a specific time, but the actual run may kick off a little later depending on system load. This small gap is normal and generally shouldn't cause a check to fail because of it.

• Threshold — the acceptable boundary for a monitor's single computed value (for example, "no more than 30 minutes old," or "between 20 and 200"). Applies to monitors that produce one number per run: Freshness, Volume, and the Field Health checks Average, Minimum, Maximum, and Sum.

• Tolerance — how many, or what percentage of, individual failing rows are allowed before an incident is raised. Applies to monitors that check every row: Numerical Range, String Length, Null, Unique, Zero, Is Before, Is After, Regex Match, Regex Not Match, Value In, Value Not In, and Custom SQL.

Alerts

• Action — a destination a rule notifies when it matches: Slack channel, Email, Webhook, or MS Teams.

• Alert rule — the unit of configuration on the Alerts page: a name, a scope, optional filters, and one or more actions.

• Custom attribute — a user-defined tag or key/value pair set on a monitor (for example, severity, domain, team), usable as a filter condition when routing alerts.

• Enabled / disabled — whether a saved rule is currently being evaluated. A disabled rule keeps its full configuration but never fires.

• Filter — a condition (monitor type, custom attribute, or monitor name) used to narrow an All-monitors rule down to the incidents you actually want.

• Muted case — a case marked to suppress alert delivery. A muted case's incidents still get evaluated against rules, but matching deliveries are suppressed rather than sent.

• Scope — whether a rule applies to All monitors (then narrowed by filters) or to a hand-picked list of Specific monitors.

• Test send — a hardcoded test message sent through a configured action's real destination, used to confirm it's wired up correctly. It doesn't evaluate rules or use real incident data.

• Trigger — the event that causes rules to be evaluated. In Phase 1, the only trigger is a new incident being created.