Sign inStart practicing
Start practicing Sign in

Data Quality and Data Observability: Checks, SLAs and Alerts

Data quality and data observability explained: freshness, volume, schema and distribution checks, data SLAs, where to test in a pipeline and alerting.

Intermediate 3 min read · Updated

Data quality is whether data is fit for the decisions made with it: complete, correct, fresh, consistent and unique enough that a dashboard or model can be trusted. Data observability is the practice of continuously monitoring datasets for problems, the way application observability monitors services. A pipeline that ran successfully can still deliver wrong data, so quality needs its own checks, alerts and owners.

The dimensions of data quality

DimensionQuestionExample check
FreshnessIs the data up to date?Latest event_time in fact_orders is within 2 hours
Volume / completenessDid all the data arrive?Today's row count is within 30% of the same weekday's average
SchemaDid the structure change unexpectedly?No columns dropped, renamed or changed type
ValidityDo values follow the rules?amount >= 0, country in the ISO list, dates not in the future
UniquenessAre there duplicates?order_id is unique in the fact table
Referential integrityDo keys match?Every customer_key exists in dim_customer
DistributionDid values shift unexpectedly?Share of null device_type jumps from 1% to 40%
Accuracy / reconciliationDoes it match the source of truth?Daily revenue equals the payment system's settlement total

Where to check in a pipeline

publishSourceIngestion checksschema · required fieldsTransform checksunique · keys · rulesBusiness checksreconcile · thresholdsConsumersQuarantinebad rows + reason
Checks at each boundary stop bad data close to where it entered, and failed checks either block publication or quarantine rows.
  • At ingestion: shape, required fields and types. Reject or quarantine malformed records instead of silently dropping them.
  • After transformations: uniqueness, key integrity, row-count conservation across joins (a join that multiplies rows is a classic bug).
  • At the business boundary: reconciliation against source systems, and thresholds on key metrics.
  • Continuously: freshness and volume monitors on important tables, often with learned baselines instead of fixed thresholds.

Blocking vs warning checks

Not every failure should stop the pipeline. Decide per check:

  • Blocking (circuit breaker): a primary key duplicate or failed reconciliation stops publication, so consumers keep yesterday's correct data rather than today's wrong data.
  • Quarantine: a few invalid rows go to a quarantine table with the reason, and the rest proceeds. Alert if the quarantined share exceeds a threshold.
  • Warning: distribution shifts and soft thresholds notify the owner without blocking, because they may be real changes in the business.

Tie checks to owners. An alert with no owning team, runbook or severity becomes noise and gets muted, which is worse than no alert.

Data SLAs and incidents

Treat important datasets like services. Agree a data SLA with consumers, such as "fact_orders for the previous day is complete and checked by 06:00 IST on 99% of days", and measure it. When something breaks, use lineage to find which downstream tables, dashboards and models are affected, tell their owners, fix forward, and backfill the affected intervals. Then add a check so the same failure is caught earlier next time.

Preventing problems upstream

Most data quality incidents start with an unannounced change in a source system: a renamed field, a new enum value, a changed unit. Data contracts move part of the responsibility to producers, who agree a schema and semantics and are warned in CI before they break consumers. Checks catch what contracts miss.

Where it’s used

Finance reporting

Revenue tables reconcile to payment settlements daily; a mismatch blocks the finance mart from refreshing.

ML features

Distribution monitors on feature tables catch a broken upstream join before it silently degrades a model.

Event pipelines

Volume monitors per event type detect when an app release stops sending a key event.

In an interview

  • List checks by dimension: freshness, volume, schema, validity, uniqueness, integrity, reconciliation.
  • Say which checks block publication and which only warn.
  • Quarantine bad rows with reasons instead of dropping them.
  • Define a data SLA and an owner for each critical table.

Further reading