Data Observability Platform for BI and Data Pipelines

The standard definition of data observability borrows from software engineering: the ability to understand the internal state of a system from its external outputs. For data, that translates to knowing whether your data is fresh, accurate, complete, and moving as expected — without manually checking each tool.

Most discussions of data observability centre on five pillars:

Freshness — Did the data arrive when expected? Is it more recent than the last update window allows?

Volume — Are row counts within the expected range? A dataset that loads 30% fewer rows than usual has probably lost data somewhere upstream.

Schema — Did column names, types, or relationships change? Schema drift is one of the most common causes of silent report breakage.

Distribution — Are column values within expected statistical ranges? A NULL rate that jumps from 2% to 40% is a data quality signal before any downstream report breaks.

Lineage — Which upstream source produced this data? If something is wrong, which downstream assets are affected?

These five pillars are necessary but not sufficient. They describe what to monitor inside a single tool. A full data observability platform connects these signals across tools: when an ADF pipeline runs late, which Snowflake table is affected, which dbt model reads from that table, which Power BI dataset depends on that model, and which reports are showing stale data to users right now.

The leading data observability platforms — Monte Carlo, Bigeye, Soda — were built to solve a warehouse problem. They excel at monitoring Snowflake, BigQuery, Redshift, and Databricks SQL at the table and column level. Anomaly detection, data quality rules, schema monitoring: all well-covered at the warehouse layer.

The gap is the BI serving layer. When data leaves Snowflake and enters Power BI or Tableau, most observability platforms lose the thread. They cannot tell you whether the Power BI dataset refreshed on schedule, whether the Tableau extract completed before the morning standup, or whether the reports your business users opened at 09:00 contained yesterday's data.

This matters because your users do not interact with Snowflake. They open reports. The failure that reaches them is not a missing row in a warehouse table — it is a dashboard that shows the wrong number, a chart that hasn't updated, or a refresh that silently failed at 04:00 while everyone slept. A data observability platform that stops at the warehouse boundary is not observing the part of the system that your users experience.

MetricSign closes this gap by monitoring both layers and connecting them: from the ingestion and transformation pipeline to the BI reports that deliver data to the business.

MetricSign has native connectors for nine layers of the modern data stack. Each connector monitors the operational health of that tool and feeds into a shared incident timeline and lineage graph.

Power BI — Dataset refresh tracking, missing refresh detection, schema change alerts, stale source data signals, per-workspace incident grouping.

Tableau Cloud — Datasource extract refreshes, Prep flow runs, extract failure detection, workbook-level impact mapping.

Azure Data Factory — Pipeline run status, activity-level failure details, retry detection, downstream dependency mapping.

Microsoft Fabric — Fabric pipeline runs, Lakehouse refresh tracking, capacity unit (CU) consumption alerts.

Snowflake — Query failure detection, scheduled task monitoring, schema change tracking.

dbt Cloud — Job run status, model-level failure detection, freshness check alerts.

Databricks — Job cluster health, pipeline run tracking, notebook failure detection.

Qlik Cloud — App reload monitoring, data connection failure detection.

Apache Airflow — DAG run status, task-level failure detection, SLA miss alerts.

All nine connectors share a unified incident timeline. When a failure in one tool causes downstream failures in another, MetricSign connects them automatically via lineage — so the first alert you receive tells you the root cause and the blast radius, not just the symptom.

The most useful thing a data observability platform can tell you is not that something failed — it is what else that failure has affected.

Lineage is how MetricSign connects the dots. When an ADF pipeline fails at 03:00, MetricSign maps the downstream chain: which Snowflake tables receive data from that pipeline, which dbt models read from those tables, which Power BI datasets depend on those models, and which reports are currently serving stale data to users.

The alert your team receives includes the root cause (ADF pipeline, activity name, error message), the downstream blast radius (three datasets, seven reports, twelve workspaces), and the time since data was last fresh. Your team knows exactly what to fix and who to notify before the first user opens a report.

Without cross-stack lineage, each tool generates its own alerts in isolation. An ADF team gets an email about a pipeline failure. Separately, a Power BI admin notices a refresh failure. A business analyst emails about incorrect numbers. Three tickets are opened for what is one incident with one root cause. Lineage collapses these into a single incident thread.

Data observability platforms built for enterprise deployment often require weeks of implementation: agent installation, pipeline instrumentation, data warehouse access policies, and professional services engagement before the first alert fires.

MetricSign connects via native APIs. There is no agent to install, no pipeline to modify, and no infrastructure to manage. OAuth-based connectors for Power BI, Tableau, and Microsoft Fabric take under five minutes each. API-key connectors for Snowflake, dbt Cloud, and Databricks are similarly straightforward.

A 45-day trial requires no credit card and no implementation project. The paid tier is €299/month per organisation — flat pricing, unlimited users, unlimited workspaces, all nine connectors included. No per-seat pricing, no per-connector add-ons, and pricing is public.