Power BI Data Observability: Beyond Refresh Status
A green refresh status means the refresh ran. It does not mean the data is correct, complete, or current. These are the four failure modes that a successful refresh can hide.
Data observability for Power BI goes beyond tracking whether refreshes succeed. Four signals fail silently after a successful refresh: schema changes that will break reports on the next run, volume anomalies that indicate incomplete or corrupted source data, schedule drift that causes data to age past its SLA, and stale source data where the source pipeline ran late. Most monitoring tools catch the first failure mode. Few catch all four.
MetricSign vs Power BI Native
Four failures that hide behind a green refresh status
A refresh success indicator means one thing: the process ran and returned without a fatal error. It does not validate the data.
Schema changes break reports silently. When a source table drops a column that a Power BI semantic model uses, the refresh continues to succeed for one or two cycles depending on the model's partition strategy. The The column X in table Y does not exist error surfaces on a future refresh — after the column has been absent for hours or days and after reports have been showing incorrect or suppressed visuals.
Volume anomalies indicate incomplete data. A sales dataset that normally loads 1.2 million rows returns 800,000 rows after a successful refresh. Power BI shows green. The sales dashboard shows understated numbers. Nobody is alerted until an analyst notices the totals don't match last week.
Schedule drift causes data to age past its SLA. A dataset configured to refresh at 06:00 consistently starts at 06:45 because of capacity contention. By 08:00 when the first users open reports, the data is already 2 hours older than it should be. The refresh succeeded. The SLA is silently broken.
Stale source data is the most invisible failure. The Power BI refresh runs on schedule. The source query runs successfully. But the source database hasn't been updated — the upstream ADF pipeline or Snowflake job ran late or silently failed. The refresh loads 24-hour-old data, reports it as current, and returns success.
What SummitView covers
SummitView covers refresh failure detection, missing refresh detection, and row count anomaly detection (via the Windows Agent on PPU/Premium/Fabric workspaces). It also adds per-table timing, which helps identify whether a slow refresh is caused by a specific table rather than the overall model.
For Power BI-only environments, SummitView closes the volume anomaly gap and the missing refresh gap. It does not detect schema changes before they cause failures, and it does not surface stale source data because it has no connection to upstream pipeline tools.
Pricing: $299/month per tenant. 14-day free trial.
What cross-stack observability adds
The schema change and stale source data gaps both require upstream visibility. Schema changes originate in source systems — a database migration drops a column, a dbt model renames a field, an ADF copy activity changes a data type. A monitoring tool with access to the upstream layer can detect these changes at the source and flag them before the downstream Power BI model is affected.
Stale source data requires knowing when the source was last updated — information that lives in the source system, not in Power BI. When MetricSign monitors both the upstream pipeline (ADF, Snowflake, dbt) and the downstream dataset (Power BI), it can surface the gap: the source table was updated 22 hours ago but the refresh schedule expects 6-hour-old data at most.
For complete Power BI data observability — covering all four silent failure modes — a tool that monitors both the BI serving layer and the upstream data pipeline layer is required.
Pricing: MetricSign €299/month per organisation. 45-day trial, no credit card.
Frequently asked questions
What is data observability for Power BI?
Data observability for Power BI means having visibility into not just whether refreshes succeed, but whether the data is correct, complete, and current after a successful refresh. It covers four failure types beyond basic refresh monitoring: schema changes (columns added, removed, or retyped in source systems), volume anomalies (row counts deviating from baseline), schedule drift (refreshes running later than expected), and stale source data (the refresh succeeded but the source data was not updated within the expected window).
Does Power BI have built-in data observability?
Power BI includes basic refresh failure notifications and 30 days of usage metrics. It does not include schema change detection, volume anomaly detection, schedule drift detection, or stale source data signals. A successful refresh status means the process completed — it does not validate the correctness or freshness of the data loaded.
What tools provide data observability for Power BI?
SummitView provides Power BI-specific observability including missing refresh detection and row count anomaly detection. MetricSign provides full-stack observability covering Power BI plus ADF, Snowflake, dbt, Databricks, Tableau, and Fabric — adding schema change detection and stale source data signals that require upstream pipeline visibility. General-purpose observability platforms (Monte Carlo, Acceldata) cover the warehouse layer but not the Power BI serving layer.
How does schema change detection work for Power BI?
Schema change detection requires monitoring the source layer — the database table, dbt model, or ADF pipeline that feeds the Power BI dataset. When a source column is dropped or renamed, a monitoring tool with access to the upstream system can detect the change and alert before the Power BI refresh runs and fails. Without upstream monitoring, schema changes surface as refresh errors after they break the model.