What Is Data Observability? 5 Pillars, Examples & Tools (2026)

Most data incidents raise no error. Nothing throws an exception when a vendor renames a field, when an upstream team loads a partition twice, or when a mobile release stops sending a column. The job exits 0, the dashboard renders, and the number on it is wrong. An orchestrator that reports every run green has said nothing about whether the output is usable.

Without checks on the output, the person who finds the problem is whoever reads the dashboard and doubts it, often a day later. Every hour in that gap is an hour of decisions made on bad data, so observability is judged by how short it makes the gap, not by how many tests exist.

Base the threshold on when the consumer reads the table. A table behind an 8:00 executive dashboard must be complete by 7:30 whatever its refresh cadence, while a table read once a week can tolerate a day of lag. A threshold set without the consumer in mind either misses incidents or pages people for delays nobody would notice.

Then allow for normal variance. Hourly jobs finish a few minutes early or late, so a threshold of exactly 1 refresh interval fires on noise. 2 intervals is a common default for hourly tables, often with a warning at 75% of the allowance so someone can look before the breach.

Choose the check cadence last, because it adds straight to detection time. The dbt documentation on source freshness advises running the check at least twice as often as your tightest SLA, so every 30 minutes for a 1 hour SLA. For orders_hourly that means every 60 minutes or less. At 15 minutes, the alert fires no later than 135 minutes after the last good load: the 120 minute allowance plus 1 check interval.

Store the thresholds as data: 1 row per monitored table with its allowed lag, tier and owner. A single scheduled query then judges every table against its own SLA, and adding a table becomes an insert instead of a deploy.

Volume monitoring counts what each load delivered and compares it with what similar loads delivered before. It is the most dependable early signal of a partial failure: an extract that hit an API rate limit, a partition that never landed, a filter that quietly began excluding a region. Spikes matter as much as drops, because a load that doubles usually carries duplicates.

A fixed floor such as "more than 0 rows" only catches total outages. A baseline catches the partial ones. In the daily orders series, the latest load delivered 10,412 rows after 2 weeks in which no load fell below 42,000: the job succeeded, the floor passed, and 78% of the orders were missing.

The simplest baseline is the mean and standard deviation of recent loads, with an alert on any load more than 3 standard deviations away. For the daily orders table, the 14 loads before the one being judged average 47,383 rows with a standard deviation of 2,734. A load of 10,412 rows is -13.5 standard deviations from that mean, far outside the band, while a floor of "more than 0 rows" would have passed it.

Elementary's volume_anomalies test for dbt uses the same shape by default: a 14 day training period of daily row counts and an expected range of 3 standard deviations around the mean.

Respect seasonality. Weekends, month ends and holidays move volume on purpose, so either compare each day with the same weekday in earlier weeks or use a window long enough that normal swings widen the band instead of paging someone every Saturday. Judge only complete buckets: a count taken at noon for a day that is half over will always look like a drop.

Schema monitoring watches for columns that appear, disappear, get renamed or change type. Most schema changes are deliberate: someone upstream improved their table without knowing a pipeline depended on the old shape. Nothing fails at the source, so the break surfaces 2 or 3 tables downstream as a failed cast or a column that is suddenly all NULL.

The reactive approach snapshots information_schema.columns once a day and diffs each snapshot with the one before it. A column in today's snapshot and not yesterday's was added, a column in yesterday's and not today's was removed, and a column in both with a different data_type changed type. A rename shows up as 1 removal plus 1 addition.

Rank the findings by damage. A removed column fails every query that selects it. A type change can corrupt results through implicit casts without raising an error. An added column is usually safe, although its downstream owners should hear about it before someone builds on it.

The proactive approach blocks breaking changes before they ship: a schema registry that enforces compatibility rules on event streams, or a data contract that turns a producer's schema into a reviewed interface. Most teams run the reactive diff on every table and keep the proactive guard for the few sources that break most often.

The quality pillar, called distribution in the original 2020 framework, looks inside the columns. A load can arrive on time, with the expected row count and an unchanged schema, and still be wrong: a join key that is NULL for 40% of rows, amounts that turned negative, a currency code that arrived in lowercase and now splits every GROUP BY in 2.

Quality checks come in 2 kinds. Rule checks encode what must always hold: order_id is unique, amount is never negative, currency is one of a known set. Statistical checks learn what normal looks like for a column, its null rate, range, cardinality and distribution, and flag drift from it. Rules catch the failures you can predict. Profiles catch the ones you cannot, and that is what observability adds to classic testing.

Profile each load, not the whole table. A null rate of 8% across a year of data can hide a single day at 40%, and that day is the one you need to see. Store each load's rates as they are measured, and alert when a rate leaves the range of its own history.

Lineage is the map of how data moves: which jobs read which tables, which tables feed which models, and which dashboards, exports and machine learning features sit at the end of each path. The other 4 pillars detect a problem. Lineage explains it, in both directions.

Upstream, it narrows the root cause. When an alert fires on a dashboard table, walk the graph toward the sources and stop at the first unhealthy table, because everything past it's a symptom. Downstream, it sizes the blast radius: before you fix, rerun or change a table, lineage lists everything that will move with it and who owns each piece.

Column-level lineage is the strongest form. It records that fct_orders.customer_id comes from raw.orders.customer_id through a specific join, so a NULL spike can be traced to the exact transformation. dbt builds table lineage from the ref() calls in a project. Outside dbt, the OpenLineage specification is the open standard: each job run emits events that name the job, the run and its input and output datasets, with facets such as the schema attached, and a backend such as Marquez, its reference implementation, assembles the graph.

A graph with missing edges stops the upstream walk short of the cause. Most teams start with the lineage their transformation tool produces and add the ingestion and BI edges over time.

The fastest way to kill an observability program is to page people for things that do not matter. Every alert needs an owner and a response sized to the damage: a breach on an executive dashboard table deserves a page, a late staging table deserves a message, and a new column deserves a line in a digest.

Tier tables by what they feed, never by their size or cost. Tier 1 holds executive dashboards, finance exports and customer-facing data: freshness SLAs of 30 to 60 minutes, every check on every load, and a page to the on-call engineer. Analyst-facing marts and recurring reports go in tier 2, with SLAs of a few hours and alerts to the owning team's channel during working hours. Staging tables and experiments make up tier 3; they get freshness and schema checks, and their results are summarized in a daily digest.

A useful alert carries what the first responder needs to start working instead of searching: what broke and by how much, the SLA it broke, the owner, the likely upstream cause, what is affected downstream and a link to the runbook. Review the alert log every month. A monitor that fired 3 times running with nobody acting on it is either miscalibrated or watching something nobody needs, and 1 upstream break that fanned out into a dozen alerts is the case for grouping alerts by their shared upstream node.

Tiers, SLAs and alert routing are what interviewers probe when they ask how you would operate a pipeline you designed. The data pipeline interview questions cover that ground, and the data pipeline practice problems let you design the pipelines these checks watch.

The 3 terms overlap and are often used interchangeably, but they answer different questions. Data quality asks whether values meet expectations, and it is tested with explicit rules. Monitoring asks whether known metrics crossed known thresholds. Observability asks whether you can explain any failure from the signals you already collect, including failures nobody predicted.

In practice they nest. Quality rules are 1 input to an observability practice, monitoring is how its signals become alerts, and lineage plus history is what lets you explain an alert instead of only receiving it. A team with a handful of critical tables and well understood failure modes can go far with quality tests alone. A team with hundreds of tables and frequent unexplained breaks needs the rest.

The market splits 3 ways: open-source building blocks, commercial platforms and the checks built into the warehouses themselves. The open-source side covers rules, anomaly tests and lineage well, and asks you to assemble, host and maintain the pieces. Commercial platforms connect to the warehouse, learn baselines for every table and add column-level lineage and incident workflows.

In a dbt project, much of the work is configuration. Source freshness takes warn_after and error_after thresholds, each a count and a period of minutes, hours or days, and reads the timestamp from loaded_at_field. Since dbt 1.9 the freshness block sits under config:, and dbt 1.10 added loaded_at_query for a custom SQL expression. Tests such as not_null, unique and accepted_values encode the quality rules, and Elementary adds volume, freshness and schema change tests that learn each baseline from the table's own history. These configurations come up often in dbt interview questions.

Outside dbt, Great Expectations and Soda Core express checks as code, OpenLineage with Marquez provides lineage, and DataHub and OpenMetadata collect lineage, ownership and test results in a catalog.

The warehouses now ship a first layer of their own. Snowflake's system data metric functions include FRESHNESS, which returns the seconds since a timestamp column's latest value or the table's last modification, plus ROW_COUNT, NULL_COUNT and SCHEMA_CHANGE_COUNT. Databricks data quality monitoring, formerly Lakehouse Monitoring, models each table's commit history and marks a table stale when a commit is unusually late. On Google Cloud, Knowledge Catalog, named Dataplex Universal Catalog until April 2026, runs data quality scans on BigQuery tables. Each covers 1 platform, which is enough when all of your data lives there.

The commercial platforms include Monte Carlo, Bigeye, Anomalo, Sifflet and Acceldata, and the field keeps consolidating: Datadog acquired Metaplane in 2025 to put data observability beside its infrastructure monitoring. Whatever you choose, test how it handles lineage across your actual stack, since root cause analysis is only as good as the graph behind it.

Most teams should not start by buying. Freshness and volume checks for the tier 1 tables are a few hundred lines of SQL and a scheduler, and writing them teaches the team what normal looks like for its own data. If the transformations already live in dbt, Elementary is the cheapest step up: anomaly tests and a report with no new infrastructure. If all of the data sits in 1 warehouse, its native checks are a second cheap step.

Buy when the numbers say so: when there are more tables than anyone can tune thresholds for, when incidents regularly cross systems dbt cannot see, or when the hours spent chasing alerts cost more than a license. A platform adds learned baselines on every table from the first day and lineage that crosses tools, so evaluate it against your worst incident from last quarter, not a demo dataset.