# Data Observability

**TL;DR:** Continuous monitoring of whether data is healthy right now: freshness, volume, schema drift, distribution shifts, and anomalies.

Data observability is monitoring for data the way APM is monitoring for services. It watches the data itself rather than the jobs that produce it, which is the distinction that makes it necessary: your pipeline can succeed, exit zero, and turn every dashboard green while writing an empty table. Green pipelines and broken data coexist comfortably, and that gap is where most data incidents live.

The standard coverage is five signals. Freshness: did this update when it should have? Volume: is the row count in the range we expect, or did it drop 90% overnight? Schema: did a column change type, get renamed, or disappear? Distribution: are the values themselves still shaped normally, or did the average order value triple because a currency field stopped converting? And lineage, which isn't a signal so much as the map that turns an alert into a diagnosis. Tools in this space include Monte Carlo, Bigeye, Soda, and the built-in test frameworks in dbt.

Most of it works by learning normal from history rather than by asking engineers to write thresholds. The system watches a table for a few weeks, learns that it lands between 02:00 and 02:20 with 40k to 60k rows and a stable null rate, and alerts on deviation. That's the only approach that scales past a few dozen tables, though it also means the first weeks are noisy and the tuning work is real.

The relationship to lineage is worth being precise about, since they ship together and get conflated. Lineage is historical and structural: where this came from and how it was built. Observability is present-tense and behavioral: whether it's healthy right now. You want both, and they compose well. Observability fires the alert, lineage tells you which upstream source caused it and which downstream consumers are affected.

For AI systems this is the monitoring layer that's most often missing entirely. Teams instrument model latency, token cost, and error rates thoroughly, and instrument the retrieval corpus not at all. But an embedding index that stopped updating three weeks ago produces no errors and normal latency while quietly serving stale context, and a document source that halved in volume just silently removed a third of what your assistant can answer about. Freshness and volume monitoring on the retrieval corpus catches a class of AI quality regression that no model-level metric will ever surface.

## Why it matters

Silent data failures are more expensive than loud ones because they're acted on. A pipeline that crashes gets fixed the same morning; a pipeline that succeeds while writing stale data feeds decisions for weeks. As AI systems increasingly read from these sources and act on them automatically, the window between corruption and consequence shortens, and the human sanity check that used to catch obviously wrong numbers is no longer in the loop.

## Example

An AI assistant answering product questions starts giving outdated pricing. No alerts fire: the model is fine, latency is normal, retrieval returns confident results with citations. The actual cause is that a vendor API change silently broke the pricing sync 18 days earlier, the ETL job kept succeeding on empty responses, and the embedding index has been serving three-week-old prices ever since. A freshness monitor on the pricing table would have caught it in an hour; a volume monitor would have caught it in one run.

## Related terms

- [Data Lineage](https://www.maximem.ai/glossary/data-lineage)
- [Observability](https://www.maximem.ai/glossary/observability)
- [Data Product](https://www.maximem.ai/glossary/data-product)
- [Dataset](https://www.maximem.ai/glossary/dataset)
- [Embedding Drift](https://www.maximem.ai/glossary/embedding-drift)
- [Agent Observability](https://www.maximem.ai/glossary/agent-observability)

---

Source: [https://www.maximem.ai/glossary/data-observability](https://www.maximem.ai/glossary/data-observability)