Databricks SQL Alerts: Conditions, Metric Views, and Data Quality Signals

1.How an alert evaluates

An alert is the monitoring tool for the whole lakehouse. It can watch business KPIs, data quality, cost trends, and operational problems, because it watches whatever a SQL query returns. The alert editor puts every part of an alert on one screen. You write and test the query, pick the SQL warehouse that runs it, set a periodic schedule, define the condition, and choose who gets notified. You can also share the alert and open advanced settings.

The condition has three parts: a value, an operator, and a threshold. The value can be the first value of a column in the result, or an aggregation such as SUM or AVERAGE across every row of one column. The threshold is a static value by default. In the documented tutorial, the alert sums the amount column of a daily taxi-fare query, triggers when the sum is greater than 4000, and runs every 5 minutes. Alerts do not accept queries with parameters, so any filter values must be written directly into the SQL.

Current alerts differ from legacy alerts in two ways that matter on the exam. First, an evaluation can only resolve to OK, TRIGGERED, or ERROR. Second, an alert cannot point at an existing saved query: each alert owns its own query definition, which you write in the alert editor. Legacy and current alerts can run side by side while you migrate. Each alert also keeps a history of past evaluations, which you can open on its details page.

Sources12

2.Alert query patterns and governed business metrics

Choosing an aggregation in the condition changes the SQL that runs. The alert wraps your query in a common table expression and aggregates over that CTE. For example, a SUM condition on SELECT 1 AS column_name runs the following query:

WITH q AS (SELECT 1 AS column_name) SELECT SUM(column_name) FROM q

One side effect follows from that rewrite. A custom notification body can't show the rows from before aggregation, because the alert only ever sees the aggregated result. A condition also checks only one column. When the rule depends on several columns, put the logic in the query and return a flag, then trigger the alert when the flag equals 1:

SELECT CASE WHEN drafts_count > 10000 AND archived_count > 5000 THEN 1 ELSE 0 END
FROM (
SELECT sum(CASE WHEN is_archived THEN 1 ELSE 0 END) AS archived_count,
sum(CASE WHEN is_draft THEN 1 ELSE 0 END) AS drafts_count
FROM queries) data

For governed business metrics, alert on a Unity Catalog metric view. This needs no special setup: an alert on a metric view works like an alert on any other dataset, and you reference the view by its fully qualified name in the alert query. The alert then evaluates the same governed metric definition that the rest of the organization uses, not a copy of the logic written into the alert.

Sources31

3.Notifications, templates, and skipped runs

Advanced settings control what reaches people. Notify on OK sends a message when the alert recovers. Empty result state sets the status to return when the query produces no rows. Template replaces the default message. Workspace admins set up notification destinations. In the standard template editor you insert variables as {{VARIABLE_NAME}}. The Markdown editor uses @VARIABLE_NAME and supports a smaller set of variables.

Alerts compete for run slots. Each workspace allows 250 simultaneous active alert runs by default. If every slot is busy when a scheduled alert fires, that run is skipped and the alert doesn't evaluate at all. To spot this, look for gaps in the evaluation history at the scheduled time. In the typical case, all the affected alerts share one schedule. To fix it, stagger the schedules, for example 01:30, 01:32, 01:34. If the workspace hits the limit consistently, Databricks Support can raise the quota.

Sources2

4.Data quality and anomaly signals

Data quality alerts come in two forms, and they work differently. A profile alert is an ordinary Databricks SQL alert. You write a query on the profile metrics table or the drift metrics table that data profiling produces, then build an alert on that query. Use it when a statistic leaves a range, such as the fraction of missing values, or when the data drifts from a baseline. Email is the default, and you can also send to a webhook, Slack, or PagerDuty.

Anomaly detection alert rules (Beta) don't use the SQL alert editor at all. You create them under Manage alerts in the Data Quality Monitoring UI, where each rule covers one catalog or one schema. When a monitored table in that scope becomes unhealthy, for example stale or with an unexpected drop in row count, each recipient receives one email per important unhealthy table. Creating a rule needs the MANAGE privilege at the level of its scope.

Sources45

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Anomaly detection alerts are Databricks SQL alerts that you build on a query and run on a SQL warehouse.Why is that wrong?

   Anomaly detection alert rules are created in the Data Quality Monitoring UI. Each one covers a catalog or a schema and emails recipients about unhealthy tables. Profile alerts are the SQL-alert form.

   Covered in Data quality and anomaly signals

2. 2.If Run now succeeds, the alert's scheduled runs must be evaluating too.Why is that wrong?

   Once all of the workspace's active alert run slots are in use, a scheduled run is skipped and never evaluates. A manual run outside that spike can still succeed.

   Covered in Notifications, templates, and skipped runs

3. 3.An alert can use a parameterized query, and the parameters are filled in at evaluation time.Why is that wrong?

   Alerts don't support queries with parameters. Filter values have to be written into the alert's SQL.

   Covered in How an alert evaluates