You cannot fix what you cannot see. Monitor the health of data itself — freshness, volume, schema, distribution — and commit to data SLAs so consumers know what to expect.
Infrastructure monitoring tells you the job ran; data observability tells you the job produced good data. It watches the data itself across a few key signals — is it fresh, is the volume normal, did the schema change, are the distributions sane — so you detect a silent quality regression before a consumer does. It is the data-world parallel to the metrics and alerting in the monitoring stack.
System monitoring "the pipeline ran, CPU was fine" (job-level)
Data observability "the pipeline produced GOOD data" (data-level)
The pillars of data observability:
FRESHNESS is the data up to date? (last load time)
VOLUME did the expected number of rows arrive?
SCHEMA did columns/types change unexpectedly?
DISTRIBUTION are values in the normal range? (nulls, min/max, cardinality)
LINEAGE what's upstream/downstream of a problem?
A job can succeed while delivering stale, half-empty, or skewed data.
Observability catches that.The two highest-value observability checks are freshness (how long since the data last updated) and volume (did roughly the expected number of rows arrive). Together they catch the most common failures: a stuck upstream feed and a partial load. Baseline them from history and alert on deviation — a table that normally gets a million rows an hour getting a thousand is a red flag even though the job "succeeded."
-- FRESHNESS: alert if the table hasn't updated recently
SELECT
max(loaded_at) AS last_load,
(now() - max(loaded_at)) AS staleness
FROM orders
HAVING (now() - max(loaded_at)) > interval '2 hours'; -- rows = stale -> alert
-- VOLUME: compare today's row count to the recent normal (anomaly detection)
SELECT count(*) AS todays_rows FROM orders WHERE load_date = current_date;
-- if todays_rows is far from the trailing 7-day average -> alert
-- (a "successful" job that loaded 1k rows instead of 1M is a silent failure)A data SLA is a promise to consumers about the data they depend on: how fresh it will be, how available, how correct. Defining SLAs (and the SLOs that measure them) turns vague expectations into an agreement — the dashboard is refreshed by 8am, 99% of days; keys are never null. This aligns the data team and its consumers and tells you which pipelines deserve the most reliability investment.
A data SLA per critical dataset — promise, measure, alert:
dataset: analytics.fct_orders
freshness SLA: updated by 07:00 UTC daily, 99% of days
completeness SLA: order_id + customer_id never null
availability SLA: queryable 99.9% of the time
correctness SLA: all dbt tests pass before publish
Turns "I thought it'd be fresh" into a measurable commitment. SLAs also
tell you WHERE to invest reliability: the datasets with the strictest SLAs
get the monitoring, redundancy, and on-call.When observability fires, you need a response, just like a systems incident: detect, assess impact via lineage, communicate to affected consumers, fix, and run a blameless postmortem that adds a check so it cannot recur silently. Treating data incidents with the same rigor as outages is what earns lasting trust in the data platform — the culmination of everything in this course.
Data incident runbook (like an outage, because it is one):
1. DETECT observability alert (freshness/volume/quality) fires
2. ASSESS use LINEAGE to find affected downstream tables + consumers
3. COMMUNICATE tell consumers "revenue dashboard is stale/suspect" NOW —
a wrong number acted on is worse than a known-late one
4. FIX repair the pipeline; backfill/reprocess the bad window
5. LEARN blameless postmortem -> add a check/contract so the same
failure can't recur silently
Data teams that run incidents this way earn durable trust. That trust is
the real product of data quality + governance.