Power BI Missing Refresh Detection: Catch Silent Failures Before Users Do

Refresh failures are easy to detect. The platform runs the refresh, the process fails, and Power BI records the failure in the refresh history. If you've configured email notifications, the dataset owner gets an alert. The mechanism is imperfect — alerts route to one inbox, there's no escalation path, and 14 datasets failing for the same upstream reason each generate a separate email — but the underlying event is at least visible.

Missing refreshes are different. Nothing fails. The scheduled refresh simply does not run. This happens when:

• A Premium or Fabric capacity hits its memory ceiling and defers scheduled refreshes that can't be processed before the next maintenance window
• A gateway cluster goes offline before the refresh starts, but recovers before Power BI registers a failure
• The data source returns an empty resultset on one cycle because an upstream pipeline ran late — the refresh runs successfully on stale data
• A scheduled refresh is silently disabled by Power BI after four consecutive failures, then never re-enabled
• Someone changes the refresh schedule and the new timing no longer covers the business window

In every case, the dataset's last refresh history entry shows success. The refresh status indicator shows green. Nobody is alerted. Users open a report and see numbers that stopped moving 18 hours ago.

74% of data quality issues are discovered by business stakeholders rather than the data team, according to Monte Carlo's 2023 State of Data Quality report (n=250). Missing refreshes are disproportionately represented in that statistic — they produce no error signal, so they go unnoticed until someone downstream notices something is wrong.

Power BI's monitoring is event-based. It records what happened: a refresh started, a refresh completed, a refresh failed. It does not record what did not happen.

To detect a missing refresh, you need schedule-learning logic: a system that knows a refresh was supposed to run at 06:00, checks at 07:00 whether it ran, and fires an alert if it didn't. Power BI's scheduler knows the configured schedule, but it does not expose an API or alerting hook for 'scheduled event did not fire within expected window.'

The closest native option is the Fabric Monitoring Hub, which shows recent activity across all semantic models in a workspace. But it shows you what ran — not what should have run and didn't. To identify a missing refresh from the Monitoring Hub, you would need to cross-reference the configured schedule against the activity feed manually, across every dataset, on a recurring basis.

The Azure Monitor integration through Premium diagnostic logs captures the same event stream — refresh started, refresh completed, refresh failed. The same gap applies: a non-event produces no log entry.

This is a structural limitation of event-based logging. You cannot log the absence of an event.

Dedicated monitoring tools solve this by inverting the logic. Instead of waiting for a failure event, they learn the expected refresh schedule for each dataset and monitor for its absence.

The approach works in two phases:

Phase 1 — Schedule learning. The tool ingests the configured refresh schedule for each dataset (available from the Power BI REST API) and validates it against observed refresh history. If a dataset is configured to refresh at 06:00 daily and the last 14 days show it consistently refreshing between 06:00 and 06:12, the tool learns that 06:12 is the expected completion boundary.

Phase 2 — Absence detection. At the expected completion time, the tool checks whether a refresh has run. If no refresh appears in the activity feed within the learned window plus a configurable buffer (typically 30 to 120 minutes), an alert fires: 'FinancialsDashboard was expected to refresh by 06:12. No refresh has been recorded. Last successful refresh: 8h ago.'

This alert fires whether the cause is a capacity deferral, a gateway timeout before start, an upstream pipeline running late, or any other mechanism that prevents the refresh from beginning. The tool does not need to know the cause — it only needs to know the expected outcome and compare it against reality.

For datasets on Fabric or Premium Per User workspaces, the tool can supplement this with row count monitoring: if the refresh ran but the row count in a key table did not increase within the expected range, the refresh succeeded against stale or incomplete source data.

Three capabilities separate tools that genuinely solve missing refresh detection from those that handle only active failures.

Schedule inference, not just schedule mirroring. The tool should learn the actual refresh cadence from observation, not just copy the configured schedule. A dataset scheduled to refresh at 06:00 but consistently delayed to 06:45 by capacity contention should have its alert window calibrated to observed reality, not the scheduled time. Tools that trigger alerts based purely on the configured time generate false positives.

Upstream pipeline awareness. A missing refresh at 06:00 often has a cause that runs at 04:00 — a Snowflake query that timed out, an ADF pipeline that hit a concurrency limit, a dbt model that failed its tests. A tool that monitors only Power BI sees the absent refresh but cannot identify the cause. A tool that monitors the full pipeline stack surfaces the upstream failure as the root cause, reducing investigation time from hours to minutes.

Configurable lateness thresholds. Not all datasets have the same SLA. A real-time trading dashboard needs a 15-minute lateness threshold. A weekly management report can tolerate a 4-hour window. The monitoring tool should let you configure thresholds per dataset, not enforce a single platform-wide setting.

For teams running Power BI alongside upstream pipeline tools — ADF, Snowflake, dbt, or Databricks — the upstream visibility matters most. A missing Power BI refresh that traces back to a Snowflake query timeout is resolved at the Snowflake layer, not the Power BI layer. Knowing which layer to look at is the difference between a 5-minute fix and a 2-hour investigation.

Both MetricSign and SummitView offer missing refresh detection as a core feature.

SummitView implements a dedicated Missing Refreshes module with schedule learning and configurable lateness thresholds. The default alert window is 2 hours past the expected refresh time. Alerts route to Email, Slack, Teams, or Webhook. The tool is Power BI-only, so the missing refresh alert shows the dataset and the expected schedule — but not the upstream pipeline cause.

MetricSign adds upstream pipeline context. When a Power BI dataset fails to refresh, MetricSign checks whether an upstream ADF pipeline, Snowflake query, dbt model run, or Fabric Pipeline produced an error in the same window. If it did, the missing refresh incident links directly to the upstream failure. The dataset alert and the pipeline failure appear as a single incident with the root cause identified — not as two separate notifications from two separate systems.

For teams running Power BI on a flat source (SQL Server, SharePoint, Excel), both tools solve the problem equivalently. For teams where Power BI is the last hop in a multi-tool pipeline, the upstream linkage in MetricSign reduces investigation time significantly.

Alerts in MetricSign route to Email, Telegram, and Webhook. Alerts in SummitView route to Email, Slack, Teams, and Webhook.