Data Quality Monitoring — Tools and Patterns for 2026

Bad data silently breaks businesses. Reports show wrong numbers. ML models train on garbage. Executives make decisions on broken dashboards. By the time you notice, the damage is done.

This guide covers data quality monitoring — the practices and tools that catch bad data before it spreads downstream.

---

What Data Quality Actually Means

Six dimensions to monitor:

1. Completeness: Are values missing where they shouldn't be?

• Are all daily records present?
• Are required fields populated?

2. Accuracy: Does data correctly represent reality?

• Are revenue numbers correct?
• Do customer counts match reality?

3. Consistency: Is the same fact stored consistently?

• Does total revenue match sum of orders?
• Are customer IDs valid across systems?

4. Timeliness: Is data current?

• Is yesterday's data loaded?
• How fresh is the dashboard?

5. Validity: Does data follow expected format/rules?

• Are emails valid emails?
• Are dates in valid range?

6. Uniqueness: Are entities not duplicated?

• Each customer appears once?
• Each transaction has unique ID?

---

The Cost of Ignoring This

Real consequences of bad data quality:

• Misleading dashboards lead to wrong business decisions
• ML models trained on broken data perform badly in production
• Reports sent to executives with wrong numbers damage credibility
• A/B tests with corrupted data produce false results
• Compliance failures from incorrect customer data
• Loss of trust in data team — eventually nobody believes the numbers

Gartner estimates poor data quality costs organizations an average of $12.9M per year.

---

Patterns That Work

Pattern 1: Tests at the Source

Test data as it enters your warehouse. Catch issues at ingestion, not after they've propagated.

-- dbt test example
-- models/sources.yml
sources:
 - name: stripe
 tables:
 - name: charges
 columns:
 - name: id
 tests:
 - unique
 - not_null
 - name: amount
 tests:
 - not_null
 - dbt_utils.accepted_range:
 min_value: 0

Run dbt test --select source:stripe daily. Failure stops downstream models.

Pattern 2: Tests on Transformations

After each transformation, verify expected properties.

-- models/orders.yml
models:
 - name: orders_clean
 columns:
 - name: order_id
 tests:
 - unique
 - not_null
 - name: total_amount
 tests:
 - dbt_utils.expression_is_true:
 expression: "= unit_price * quantity"

Catches: incorrect joins, math errors, edge cases.

Pattern 3: Anomaly Detection on Metrics

Track key metrics over time. Alert on anomalies.

# Daily revenue
SELECT 
 date,
 SUM(amount) as revenue
FROM orders
GROUP BY date

# Compare yesterday to 30-day average
# Alert if delta > 30%

Tools like Monte Carlo, Anomalo, Bigeye automate this. Simple version with Slack alerts via Airflow works too.

Pattern 4: Reconciliation

Cross-check critical numbers across systems.

-- Does Stripe payment total match what we recorded?
WITH stripe_total AS (
 SELECT SUM(amount) as total FROM stripe.charges
 WHERE DATE(created) = CURRENT_DATE - 1
),
internal_total AS (
 SELECT SUM(amount) as total FROM internal.payments
 WHERE DATE(payment_date) = CURRENT_DATE - 1
)
SELECT
 stripe_total.total as stripe,
 internal_total.total as internal,
 stripe_total.total - internal_total.total as diff
FROM stripe_total, internal_total
WHERE ABS(stripe_total.total - internal_total.total) > 100

Alert if diff > threshold.

Pattern 5: Freshness Monitoring

Make sure data is current.

-- When was data last loaded?
SELECT MAX(updated_at) as last_load
FROM warehouse.orders

-- Alert if > 1 day stale (assuming daily loads)

---

Tools

Great Expectations

Python framework for data validation.

import great_expectations as ge

df = ge.read_csv("data.csv")

# Define expectations
df.expect_column_to_exist("email")
df.expect_column_values_to_not_be_null("user_id")
df.expect_column_values_to_match_regex("email", r"^[\w.-]+@[\w.-]+\.\w+$")
df.expect_column_values_to_be_in_set("status", ["active", "inactive", "pending"])
df.expect_column_values_to_be_between("age", 0, 120)

# Validate
results = df.validate()
print(results)

Generates docs of what your data "should" look like. Strong for one-off validation.

dbt Tests (Most Common in 2026)

If you're using dbt (and you probably should be — see dbt Tutorial):

models:
 - name: customer_lifetime_value
 columns:
 - name: customer_id
 tests:
 - unique
 - not_null
 - name: ltv
 tests:
 - not_null
 - dbt_utils.expression_is_true:
 expression: ">= 0"

Run as part of pipeline. Failures block deployment.

Built-in tests:

• unique
• not_null
• accepted_values (must be in list)
• relationships (foreign key validation)

Plus dbt_utils package and dbt_expectations for more.

Monte Carlo (Commercial)

Observability platform for data. Automatically detects:

• Data freshness issues
• Volume anomalies
• Schema changes
• Field-level changes
• Custom monitors

Sets up monitoring without you writing tests. Expensive but valuable for large data teams.

Anomalo

Similar to Monte Carlo. Uses ML to detect anomalies without explicit rules.

Open Source: Soda Core

Free alternative to commercial tools. Define checks in YAML:

checks for orders:
 - row_count > 1000
 - missing_count(email) = 0
 - duplicate_count(order_id) = 0
 - freshness(created_at) < 1d

---

Real Monitoring Stack

A typical mature setup:

1. Source ingestion → Soda or Great Expectations tests
 ↓
2. dbt transformations → dbt tests at every model
 ↓
3. Final marts → dbt tests + business rule validations
 ↓
4. Production dashboards → Monte Carlo monitoring
 ↓
5. Alerts → Slack #data-quality
 ↓
6. Incident → On-call rotation responds, fixes, documents

Each layer catches different issues.

---

What to Monitor (Priority Order)

Tier 1: Critical Business Metrics

If these break, executives notice immediately.

• Daily revenue
• Active users
• New signups
• Conversion rates

Monitor with high sensitivity. Page someone if these break.

Tier 2: Reporting Tables

Tables that feed dashboards and recurring reports.

• Customer dimensions
• Order facts
• Product catalog

Monitor for freshness, completeness, schema changes.

Tier 3: Raw Data

Source data quality.

• Stripe webhooks
• Marketing data
• Product analytics

Monitor for missing data, format changes from vendors.

Tier 4: Internal Datasets

Tables nobody outside data team uses.

Monitor lightly. Schema enforcement matters; field-level less critical.

---

Common Anti-Patterns

Testing Everything Equally

Not all tables matter equally. Critical revenue tables need strict tests; internal analyst scratch space doesn't.

Alert Fatigue

If alerts fire every day, people ignore them. Tune thresholds carefully. Severity matters.

Tests Without Runbooks

When a test fails at 3am, on-call shouldn't have to figure out what to do. Each test → linked runbook.

Reactive Only

Adding tests after each incident is firefighting. Proactive: add tests during initial development.

No Ownership

Without clear ownership, tests bit-rot. Each table should have an owning team that maintains tests.

Wrong Granularity

Too coarse: "table has > 0 rows" is useless. Too fine: testing every value individually is impractical. Aim for important properties.

---

Building a Data Quality Program

Phase 1 (Week 1-2): Identify Critical Datasets

List the 5-10 most-critical tables. Determine which dashboards/decisions depend on them.

Phase 2 (Week 3-4): Add Basic Tests

For each critical table:

• Uniqueness on ID column
• Not-null on required fields
• Freshness check (data loaded recently)
• Row count sanity check (not zero, not 10x normal)

Phase 3 (Month 2): Add Business Logic Tests

• Revenue reconciliation between systems
• Business rule validations (no negative amounts, etc.)
• Cross-table consistency checks

Phase 4 (Month 3): Add Anomaly Detection

Statistical monitoring on key metrics. Alert when distributions shift.

Phase 5 (Month 4+): Mature Operations

• Documented runbooks for failures
• On-call rotation
• Quarterly review of test coverage
• Incident postmortems

This is sustainable. Trying to do it all at once burns out the team.

---

Communicating With Stakeholders

When data quality fails:

Don't Hide It

Pretending the dashboard is correct when it isn't damages trust permanently.

Be Specific

"Revenue dashboard shows wrong numbers" is vague. "Stripe webhook missing 4 transactions on 2026-05-14 affecting Tier 1 revenue dashboard. Fix in progress, expected resolution 2 hours" is useful.

Show the Impact

"This affects: daily revenue dashboard, finance reports, executive dashboard. NOT affected: customer-facing data."

Have a Plan

What you're doing to fix it. Timeline. What's permanent fix vs temporary.

Document

Incident postmortems. What happened, why, what's changing to prevent recurrence.

---

ROI of Data Quality

Hard to measure directly. Useful proxies:

• Time to detect issues: Before monitoring: weeks. After: hours.
• Time to fix: Documented runbooks cut this in half.
• Stakeholder trust: Survey periodically.
• Number of incidents in flight: Track over time, expect decrease.

A medium-sized data team typically spends 10-20% of capacity on data quality. The alternative (constant firefighting) costs more.

---

FAQ

Q: Tests or monitoring — which first? A: Tests first (deterministic checks on transformations). Monitoring second (anomaly detection on metrics). Both eventually.

Q: dbt tests or Great Expectations? A: If you use dbt, use dbt tests. They're easier to maintain alongside models. Great Expectations is better for non-dbt environments.

Q: Are commercial tools worth it? A: For large data teams (10+ engineers), often yes. They save labor on monitoring setup. For small teams, open-source covers most needs.

Q: How many tests is enough? A: Aim for ~5-10 tests per critical table. More for highest-stakes data. Less for internal-only tables.

Q: Who should own data quality? A: Each team owns quality of data they produce. Data platform team provides tools and governance. CDO/VP Data sets standards.

---

Related Articles

• dbt Tutorial — Data Engineering for Analysts
• Data Engineering vs Data Science
• Best Data Science Tools 2026
• Data Cleaning: 80% of Data Scientist's Job

---

Bottom Line

Bad data quality silently destroys data teams' credibility and business value. Monitoring is the discipline that prevents this.

Start with dbt tests on critical tables. Add anomaly detection for key metrics. Document runbooks. Establish on-call. Communicate openly about issues.

The best teams in 2026 treat data quality the way software teams treat tests and uptime — non-negotiable, owned by everyone, instrumented systematically.

Last verified: May 2026