03:07 UTC. A Slack card on the phone said orders_daily · completeness · Unhealthy. Nine minutes of staring at that card produced exactly one new piece of information: it was still Unhealthy. The on-call SSH’d into a notebook, ran three lines against system.data_quality_monitoring.table_results, and the answer was on screen in eighteen seconds: completeness.daily_row_count.last_value = 412 against a min_predicted_value of 9,400. The email had been carrying nothing the whole nine minutes.

Most Databricks anomaly-detection posts on the practitioner web stop at the dashboard screenshot — a green-then-red sparkline with the word Unhealthy overlaid in a coral pill. None of them carry the gap. The gap was always there, two struct levels deep, in the row the email pretends does not exist. This note is that row: the corrected struct path, the on-call query with the column-name landmine the docs hide, and a measured detection latency on a controlled-trial workspace.

The screenshot is what goes in the post-mortem. The row is what goes in the runbook. One is a story; the other is a contract.

The rest of this note is the contract. The bench that made the break unambiguous, the row the system table wrote, the query that pulls it (with the one column name that has to be right or nothing returns), and the UI alert that fires on the same write but never quotes the row.

Before the three-line query from §1 could return anything worth waking somebody for, the bench had to make the breakage impossible to read any other way. Two tables on a trial workspace, both governed by Lakehouse Monitoring with schema-level anomaly detection (Public Preview, Feb 2026) turned on. orders_daily seeded with 14 days of synthetic rows, ~10,000 per calendar day, low variance. events_hourly seeded with hourly commits over the same window. The monitors:

Neither break is subtle. The completeness break is a row-count plunge of more than an order of magnitude versus the seed band; the freshness break is a hard stop. That is deliberate. The bench is not testing the detector’s sensitivity — that belongs in a separate note. It is making detection so easy that any latency measured is a lower bound on what to expect in the wild.

First break: the row-count plunge. The seed has ~10,000 rows for every prior day; we insert 412 for today and commit. The completeness monitor is the only thing watching, and its band sits between 9,400 and 10,800.

-- 14-day seed already exists with ~10,000 rows/day. Today: inject a plunge.
INSERT INTO main.bench.orders_daily
SELECT *
FROM   bench.synth.orders_template
WHERE  order_date = current_date()
LIMIT  412;   -- expected ~10,000, injecting ~ 412

COMMIT;
-- Note the wall-clock to the second. This is T_break.

Wall-clock at COMMIT — recorded to the second — is T_break. The detector now owes us an Unhealthy row.

Second break: the freshness producer. The hourly workflow has a 90-minute threshold; pausing it puts a hard stop on last_value inside freshness.commit_freshness and lets wall-clock do the rest.

# Workflow `events_hourly_producer` runs every 60 min and COMMITs one
# batch into main.bench.events_hourly. We pause it; the threshold is 90 min.
databricks jobs cancel-all-runs --job-id $EVENTS_HOURLY_JOB_ID
databricks jobs reset --job-id $EVENTS_HOURLY_JOB_ID \
  --new-settings '{"schedule":{"pause_status":"PAUSED"}}'
# Record wall-clock. This is T_break for freshness.

Two T_break values on the wall. Whatever Lakehouse Monitoring writes into table_results from here on is the response to one of these two commits.

Back to the row from §1 — the one the on-call pulled at 03:16 UTC after nine minutes of an unhelpful Slack card. Here is what was inside it. The shape catches a lot of readers out: table_results has four top-level struct columns — freshness, completeness, downstream_impact, root_cause_analysis — and the actual / expected numbers live nested inside the first two. total_row_count and daily_row_count are not top-level columns; they are measures inside completeness. The discriminator is not which struct is populated — it is the nested status field on each measure (Healthy, Unhealthy, or Unknown).

The completeness row from the bench, captured at first appearance. JSON serialisation is the Databricks default; field order is preserved for readability:

{
  "catalog_name": "main",
  "schema_name":  "bench",
  "table_name":   "orders_daily",
  "completeness": {
    "daily_row_count": {
      "status":               "Unhealthy",
      "last_value":           412,
      "min_predicted_value":  9400,
      "max_predicted_value": 10800
    },
    "total_row_count": {
      "status": "Healthy"
    }
  },
  "downstream_impact": {
    "impact_level": 2,
    "num_downstream_tables":           4,
    "num_queries_on_affected_tables":  31
  },
  "root_cause_analysis": {
    "upstream_jobs": [
      { "job_id": "812944",
        "run_page_url": "https://<workspace>/jobs/812944/runs/47" }
    ]
  },
  "event_time": "2026-05-18T03:07:00Z"
}

The number that justifies the 03:00 wake-up is completeness.daily_row_count.last_value = 412 against min_predicted_value = 9400. That is the whole post in two struct levels. The 14-day seed window concept lives in the prose and the docs, not as a column — there is no seed_window_days field on the row.

And the freshness row from the same run. commit_freshness is an array of structs (one entry per measured commit), and the “147 minutes since last commit” quoted in the email body is derived — current_timestamp() - last_value. The 90-minute threshold from the producer’s configuration shows up as the model’s predicted_value for the next commit, not a literal threshold column.

{
  "catalog_name": "main",
  "schema_name":  "bench",
  "table_name":   "events_hourly",
  "freshness": {
    "commit_freshness": [
      {
        "status":           "Unhealthy",
        "error_code":       "FRESHNESS_EXCEEDED",
        "last_value":       "2026-05-18T00:45:00Z",
        "predicted_value":  "2026-05-18T01:45:00Z"
      }
    ]
  },
  "event_time": "2026-05-18T03:12:00Z"
}

At event_time = 03:12 UTC, with last_value = 00:45 UTC, the gap is 147 minutes. That number is one subtraction the on-call does in the SQL editor; the row itself just carries the timestamp.

The email body is “a monitor became unhealthy.” The row is “orders_daily.completeness.daily_row_count.last_value is 412 against a min predicted of 9,400.” The first sentence wakes you up. The second tells you what to do. — Field report, §3

The three-line query from the dek — the one that turned nine minutes of staring at Slack into eighteen seconds of having the gap on screen — is below. There is one place the copy-paste breaks for new readers, and it is the column name: system.data_quality_monitoring.table_results uses catalog_name and schema_name, not table_catalog / table_schema like several other system tables. A query with the wrong names returns zero rows with no error. At 03:00 this is the kind of difference that costs a quarter of an hour.

-- Replace catalog/schema or drop the predicates to widen the search.
SELECT
  table_name,
  completeness,
  freshness,
  downstream_impact,
  root_cause_analysis,
  event_time
FROM   system.data_quality_monitoring.table_results
WHERE  catalog_name = '<your_catalog>'
  AND  schema_name  = '<your_schema>'
  AND  (completeness.daily_row_count.status = 'Unhealthy'
    OR completeness.total_row_count.status = 'Unhealthy'
    OR exists(freshness.commit_freshness,
              x -> x.status = 'Unhealthy'))
ORDER BY event_time DESC
LIMIT  10;

That returns the ten most recent rows with at least one Unhealthy measure in completeness or freshness. The three struct columns come back as nested values; in the SQL editor each one is one expand-arrow away from the gap.

For the two check types on the bench, the on-call wants two sharper queries — the ones that turn the nested row into a single number per output column. The completeness gap is a straight projection of two scalar fields:

SELECT
  table_name,
  completeness.daily_row_count.last_value          AS actual_rows,
  completeness.daily_row_count.min_predicted_value AS expected_min,
  completeness.daily_row_count.max_predicted_value AS expected_max,
  completeness.daily_row_count.status              AS status
FROM   system.data_quality_monitoring.table_results
WHERE  completeness.daily_row_count.status = 'Unhealthy';

That returned a single row: orders_daily, actual_rows = 412, expected_min = 9,400, expected_max = 10,800, status = Unhealthy. The gap is a subtraction in the reader’s head; the row carries the operands.

Freshness is harder, and this is the part the docs gloss over. freshness.commit_freshness is an array, so the last-value timestamp comes out of element zero, and the “147 minutes since commit” quoted in the email body has to be computed in SQL with timestampdiff. Array indexing inside a struct path; not pretty, but it is the only way:

SELECT
  table_name,
  freshness.commit_freshness[0].last_value AS last_commit_ts,
  timestampdiff(MINUTE,
                freshness.commit_freshness[0].last_value,
                current_timestamp())       AS minutes_since_commit,
  freshness.commit_freshness[0].status     AS status
FROM   system.data_quality_monitoring.table_results
WHERE  freshness.commit_freshness[0].status = 'Unhealthy';

Run on the bench at 03:16 UTC, this returned events_hourly, last_commit_ts = 00:45 UTC, minutes_since_commit = 151, status = Unhealthy. (Detection itself fired four minutes earlier at event_time = 03:12 UTC with 147 minutes of gap; the on-call query just runs whenever the on-call runs it.) Total wall-clock from opening the SQL editor to having both gaps on screen: 18 seconds.

The same row that surfaced the gap in §1 also fires the UI alert. They share the write: one append to table_results, two surfaces. The UI surface is configured outside SQL. As of the Beta release in March 2026 there is no Terraform resource for the alert routing yet (the monitor itself does have one). The path is short: Catalog Explorer → the table → Quality tab → Create alert. Three things to set, and one new affordance in Catalog Explorer worth knowing about.

Wired correctly, the alert payload that lands in email or Slack is the Databricks default summary — monitor name, table name, status, timestamp, and a deep link back to the DQM tab. It does not include the last_value or min_predicted_value values; for those, the on-call goes to the row. The post above is, in effect, the case for treating the row as the alert and the email as the doorbell.

There is one new piece of UI worth flagging: in the March 2026 Public-Preview update, Catalog Explorer started badging tables in the tree with a health indicator (a small coloured dot) whenever any nested measure is Unhealthy or Unknown. It reads off the same status fields. It is the first surface where a browsing on-call sees the breakage without opening the Quality tab.

The UI alert is one click to create and one screen to read. The row in the system table is what makes the on-call useful. Both ship from the same write; only one of them carries the gap.