Data Quality Monitoring Tools: What Actually Works in 2026

Ask five data engineers what data quality monitoring means and you will get five different answers. One will describe dbt tests checking for nulls and referential integrity. Another will describe Azure Monitor alerts on pipeline failures. A third will describe a Monte Carlo dashboard tracking row count trends in Snowflake. A fourth will describe a process that checks whether the Power BI dashboard refreshed on time. The fifth — the one supporting executive dashboards — will describe manually checking whether the revenue number looks right before the Monday meeting.

All five are correct. Data quality monitoring spans the entire chain from source system to business consumer, and failures occur at every layer.

The most visible layer is pipeline execution: did the ADF pipeline run? Did the dbt job complete? Did the Snowflake task succeed? Infrastructure and pipeline monitoring tools cover this layer well. A failure here produces an error event, which can be detected and alerted.

The second layer is data correctness within a successful run: did the table that loaded successfully contain the right number of rows? Did a schema change cause a column to go missing? Is the data older than its SLA allows even though the pipeline reported success? Data quality frameworks (Great Expectations, dbt tests, Soda) specialize in this layer — they run assertions against the data itself after the pipeline completes.

The third layer — the one most monitoring tools miss — is the BI serving layer: is the Power BI report or Tableau workbook loading correct, fresh, complete data? A warehouse table can pass all its dbt tests and still produce a stale dashboard if the Power BI refresh scheduled for 06:00 never started, or if a capacity throttle delayed it by three hours.

The fourth layer is the consumer experience: is the data fresh enough for the decisions being made against it? A finance team making pricing decisions needs data from this morning. A supply chain team running daily batch plans needs data from yesterday by 07:00. Neither team is watching Azure Monitor. They are opening a report and trusting what they see.

Effective data quality monitoring connects all four layers. A failure at any point propagates downstream. The relevant question for any monitoring tool is: at what point in this chain does it stop watching?

Infrastructure monitoring tools are designed for platform engineers. They ingest logs and metrics from cloud services — Azure resource logs, Datadog APM traces, CloudWatch events — and expose them for querying and alerting. For a data platform running on Azure, this means ADF pipeline run logs, Databricks cluster metrics, Fabric capacity utilisation, and Snowflake connector telemetry can all flow into Azure Monitor's Log Analytics workspace and be queried with KQL.

This is genuinely powerful for infrastructure-layer monitoring. When an ADF integration runtime is offline, Azure Monitor can alert immediately. When Databricks cluster startup is taking longer than usual, Datadog can graph the trend. When Azure SQL DTU utilisation exceeds 80%, a custom alert can fire before the pipeline hits the limit.

Four categories of quality problems fall outside what infrastructure tools cover by default.

First, missing run detection is architecturally out of scope. Infrastructure monitoring is event-driven: it records events that occur. A pipeline that never starts produces no event. No log entry, no metric spike, no alert. The absence of an expected run is invisible to infrastructure tools without significant custom development — building a synthetic monitor that asserts the presence of a run event within a time window, for every pipeline, and maintaining it as schedules change.

Second, BI-layer monitoring is either absent or limited. Azure Monitor can ingest Power BI diagnostic logs, but only for Premium or Fabric capacities, only with diagnostic settings configured per workspace, and only queryable via KQL — not via a purpose-built monitoring interface. Tableau is not covered. The experience of connecting Azure Monitor to Power BI and building useful alerts requires 4–8 hours of setup before seeing a single alert.

Third, cross-stack lineage requires manual construction. Azure Monitor collects logs from each service separately. Correlating an ADF failure at 03:00 with a Power BI failure at 04:00 requires writing a KQL join across two log tables, knowing the table names, understanding the schema, and running the query manually after the fact. There is no automatic grouping of related failures into a single incident.

Fourth, data correctness signals are absent. Infrastructure tools measure execution — did the process run, how long did it take, did it error? They do not measure what the process produced. A Snowflake task that ran successfully but loaded 40% fewer rows than expected returns a healthy metric from Azure Monitor's perspective.

For teams whose primary need is infrastructure reliability — preventing platform outages, monitoring cluster performance, tracking capacity utilisation — Azure Monitor and Datadog are strong choices. For teams whose primary need is ensuring that BI consumers receive correct, fresh, complete data from reports, infrastructure tools address only the pipeline execution slice of a much broader problem.

Data quality frameworks approach the problem from the opposite direction. Instead of monitoring infrastructure events, they validate the data itself. Great Expectations defines expectations — assertions about what the data should look like — and evaluates them against actual tables or dataframes. dbt tests embed assertions directly in the transformation layer: a not_null test on a column, a unique test on a primary key, a relationships test across tables.

This is where infrastructure tools stop and frameworks start: checking that a column that arrived in a Snowflake table is not null, that a join key exists in both tables, that a row count falls within a historical range, that a value distribution matches expectations. These are genuinely data quality checks — not just execution checks.

Frameworks like Great Expectations and dbt tests are most powerful when embedded in the transformation pipeline: running after a dbt model build, validating the output before it is promoted to a production schema, blocking the downstream load if an assertion fails. When a dbt test fails, the failure is caught at the transformation layer before the warehouse table is consumed by Power BI.

Three limitations are significant for production BI environments.

First, frameworks require code to configure and maintain. Great Expectations expectations are defined in Python or YAML. dbt tests are YAML or SQL macros. Every assertion must be written by someone with data engineering skills. Adding a new check for a new business rule requires a code change, a pull request, a deployment. For a team of five that includes two data engineers, this is fine. For a team of two analysts supporting a Power BI environment, this is a hard dependency on engineering resources that may not be available.

Second, frameworks do not monitor the BI serving layer. A dbt test that passes confirms that the Snowflake table contains valid data. It says nothing about whether the Power BI dataset that consumes that table refreshed successfully, refreshed on time, or is currently serving that data to users. The dbt test boundary ends at the warehouse table. What happens in the BI layer is invisible.

Third, frameworks do not detect execution-level failures outside the transformation step. If the ADF pipeline that loads data into Snowflake fails before dbt even runs, the dbt tests do not fire — there is no new data to test. A missing run upstream produces silence in the framework. Combining a dbt test failure with a pipeline execution failure requires connecting two separate monitoring systems.

For teams doing serious data engineering work — maintaining dbt models in a structured development workflow, caring about data correctness at the warehouse layer — dbt tests and Great Expectations provide coverage that no infrastructure tool or BI monitoring tool replicates. They are the right tool for cell-level data profiling, referential integrity checks, and business rule validation at the transformation layer.

The gap they leave is the BI serving layer and the orchestration layer above the transformation step. A complete monitoring picture requires coverage beyond the warehouse table boundary.

BI-native monitoring tools are designed around a different entry point: the report. They ask not "did the pipeline run?" or "does the table contain valid data?" but "is the report that business users are relying on serving correct, fresh, complete data right now?"

MetricSign monitors the full data chain — ADF, Snowflake, dbt Cloud, dbt Core, Databricks, Microsoft Fabric, Tableau Cloud, and Power BI — with the report as the end point. Every monitoring signal in the system traces back to the question of whether a specific report or dataset is serving reliable data.

This produces three capabilities that infrastructure tools and data quality frameworks do not offer.

Cross-stack incident grouping. When a Snowflake query times out at 02:00, the ADF pipeline that depends on it fails at 02:15, the dbt model that reads from the ADF output fails at 02:45, and three Power BI datasets that depend on the dbt model fail at 04:00 — MetricSign groups all of these into one incident, identifies the Snowflake timeout as the earliest failure in the chain, and links the affected Power BI reports directly in the incident view. An on-call engineer receives one alert, not four.

Missing run detection without custom code. MetricSign learns the expected schedule for each pipeline, refresh, and job by observing its history. When an expected run does not appear within the learned window, an incident opens automatically. This requires no custom monitor configuration, no synthetic assertion scripts, and no code changes when schedules change.

No-code setup for the BI layer. Connecting Power BI requires a service principal with workspace access. Connecting Tableau Cloud requires an API token with Site Admin access. Connecting ADF requires a service principal with Contributor access to the data factory resource. All three are configured through a UI, not code. Most environments are fully connected within one working session.

What MetricSign does not do: cell-level data profiling. It detects volume anomalies (row counts deviating from baseline) and schema changes (columns added or removed), but it does not run arbitrary SQL assertions against table contents. A check that verifies "the order_status column contains only valid status codes" or "the revenue column sum matches the finance system total" requires a data quality framework. dbt tests or Great Expectations are the right tool for that use case — and they pair well with MetricSign, which covers the orchestration and BI serving layers that frameworks leave unwatched.

Pricing: €299/month per organisation — flat rate, unlimited users, all connectors included. 45-day trial, no credit card.

The decision depends on where your quality failures actually surface and who is accountable for detecting them.

If your primary concern is infrastructure reliability — preventing ADF outages, monitoring Databricks cluster health, tracking Snowflake warehouse utilisation, maintaining Azure resource availability — start with Azure Monitor or Datadog. These tools have native connectors for the Azure and cloud infrastructure layer, strong alerting flexibility, and mature incident routing integrations (PagerDuty, Opsgenie). Budget for 4–8 hours of setup per service and ongoing KQL/query maintenance as your environment changes.

If your primary concern is data correctness at the transformation layer — ensuring that dbt models produce tables with valid primary keys, no unexpected nulls, referential integrity across fact and dimension tables — use dbt tests. They are zero additional cost if you already run dbt, they live in the same repository as your transformation code, and they fail the pipeline run before bad data reaches production. For more complex assertion logic or for environments not using dbt, Great Expectations provides a comprehensive Python-native framework. Budget for data engineering time to write and maintain the test suite.

If your primary concern is BI reliability — ensuring that Power BI reports and Tableau workbooks are refreshing on schedule, that upstream pipeline failures are detected before analysts open stale dashboards, and that on-call engineers receive a single grouped alert rather than one notification per broken report — use a BI-native monitoring tool like MetricSign. Setup requires no data engineering skills, covers the layers that frameworks and infrastructure tools leave unmonitored, and provides cross-stack lineage automatically.

For most production data environments, the answer is a combination. dbt tests run at the transformation layer to validate data correctness. MetricSign monitors orchestration, freshness, and the BI serving layer. Azure Monitor handles infrastructure-level platform reliability for teams with a dedicated platform engineering function. The three tools do not overlap — they cover adjacent slices of the monitoring surface.

The most common mistake is assuming one tool covers all three. A team that relies on Azure Monitor alone will miss cell-level data correctness problems and BI-layer failures. A team that relies on dbt tests alone will miss missing runs and Power BI refresh failures. A team that relies on BI monitoring alone will miss data correctness problems that pass through the warehouse layer silently. The question is not which single tool to buy — it is which layer of the chain is currently unmonitored and what the cost of a failure at that layer is.