The metadata you already have

Checking data means reading rows. Reading rows on a large table costs money and time, which is why the checks that read rows get run nightly at best and quietly disabled by the third invoice. Metadata is different: row counts, load timestamps, column lists and null counts are either already stored by the warehouse or computable in a single cheap aggregate. You can check them every 15 minutes without anybody noticing the bill.

That cost difference decides the shape of the practice. Metadata monitors are the layer that runs constantly and tells you something moved. Row-level tests are the layer that runs at build time and tells you this specific rule broke. You want both, and they are not substitutes.

• Signal - one measurable property of a table over time. Freshness, volume, schema, distribution and lineage are the five that carry the practice, and sessions 2 to 7 take one each.
• Monitor - a query, a threshold and a destination. Drop any one and you have a dashboard nobody reads.
• Data downtime - the hours in which a table was wrong, late or missing while people were using it. Detection time is the part you control.
• False page - an alert on a night when nothing was actually wrong. The currency you spend to buy detection, and the reason precision matters more than coverage.
• MTTD - mean time to detect, in hours, from the moment a table went wrong to the moment a human knew. Session 8 measures yours.
• Blast radius - everything downstream of a broken table: models, dashboards, exports, one reverse-ETL job into the CRM that nobody documented. Session 7.

Freshness asks whether the data arrived when it was supposed to. The naive version compares max(updated_at) against the current time and fires if the gap is too large. It works, and it is where everybody starts, and session 2 shows why a fixed deadline is the wrong shape for the question.

Two traps worth knowing before you point this at anything real. A table that is rebuilt in full every night has an updated_at that jumps to now on every load, which tells you the job ran rather than whether the data is current: for those, timestamp the source event, not the row write. And a partition that arrives empty still updates the table's metadata in some warehouses, so a freshness check that passes on an empty load is measuring the pipeline's mood rather than the data.

A row count on its own means nothing. A row count next to the last four values of the same weekday means a great deal, because grocery orders on a Saturday are not grocery orders on a Tuesday and a band wide enough to hold both is too wide to catch a missing shard.

This is the single most common reason a volume monitor gets switched off: it was set as a fixed band, it fired every weekend, and by week three somebody muted it. Session 3 does the arithmetic properly. Tonight just record the number every night, because you cannot compare against history you never stored.

Duplicate rate and null rate are the two signals that catch the failures which leave the row count looking healthy. A merge key that changes upstream can double some rows and drop others, landing you within a percent of a normal night while every downstream sum is wrong.

• Duplicate rate beats a uniqueness test on a big table because it degrades gracefully. A hard uniqueness assertion either passes or fails the build; a rate tells you it went from 1 percent to 8 percent, which is the sentence you need in the incident channel.
• Null rate per column is worth storing for every column you care about, not just the key. The column that goes null is almost never the one you would have picked.
• Store the results in a small metrics table, one row per table per night. That table is the history every later session compares against, and if you start it tonight, session 8 has something real to read.

Every monitor buys detection with false pages. The exchange rate is the thing to watch, because a person who is woken for nothing twice in a week stops treating the channel as real, and from that point your monitors are decoration. There is no clean published threshold for where that happens, and the honest version is that it depends on the team and how the page arrives. What is not in doubt is the direction: alert fatigue is the documented failure mode of monitoring systems in software operations and in clinical settings alike, and the fix is always fewer, better alerts rather than more.

So the operating rule for the rest of this track: a monitor that fires more than about once a week without a real cause gets retuned or deleted. Not muted. Session 8 puts a number on what noise costs you, and the number is uncomfortable.

Three homes, three jobs, and picking the wrong one is why teams end up with the same check in two places disagreeing with itself.

The third one is a different discipline with its own tooling and its own course. What lives here is the layer that runs whether or not anybody's pipeline ran, because the most expensive incidents are the ones where nothing failed.