How to Get Notified When a Power BI Dataset Refresh Fails

There's a simple test for whether your Power BI monitoring is working: who finds out first when a scheduled refresh fails? If the answer is a business user opening a report and noticing something is wrong, your alerting is not doing its job.

The engineering goal is to be notified at the moment of failure — or before, if the failure is predictable — with enough context to start fixing without additional investigation. The notification that says "a refresh failed" at the same time a business user notices wrong data has no value. The notification that says "Sales Overview failed at 06:14, gateway error DM_GWPipeline_Client_GatewayUnreachable, last success 06:04 yesterday" means the engineer is investigating before anyone in the business opens the report.

There are four main approaches to getting there, ranging from built-in Power BI features to dedicated monitoring tools. Each has a different scope, different setup cost, and different blind spots.

Power BI Service has a built-in refresh failure notification. In dataset settings, you can configure up to two email addresses to receive a notification when a scheduled refresh fails. Setup takes less than a minute.

What it covers: import-mode dataset scheduled refresh failures. The email arrives within a few minutes of the failure and includes the dataset name and workspace.

What it doesn't cover: the error code or root cause (the email body is generic), silent failures where the refresh succeeds but loads wrong data, dataflow refresh failures, DirectQuery connectivity issues, scheduled refresh cancellations due to timeout, and any failure that doesn't produce a Power BI-level error — such as an upstream ADF pipeline that ran and copied zero rows.

For a team with two or three datasets and an engineer who checks email, built-in notifications are a reasonable starting point. For a production environment with 20 or more datasets spread across multiple workspaces, the limitations compound: notifications go to up to two email addresses per dataset, there is no consolidated view, and there is no way to route different dataset failures to different teams or on-call systems.

Power BI exposes refresh history through the REST API (GET /datasets/{id}/refreshes). Azure Monitor can capture Power BI audit events through the Diagnostics settings on a Power BI Premium or Fabric capacity. Combining both gives you programmatic access to refresh status that can drive custom alerting logic.

What it covers: refresh failures for any dataset you explicitly poll, with the ability to extract the error code from the API response. Azure Monitor captures capacity-level events including refresh start and completion. Logic Apps or Azure Functions can watch for failure events and send alerts to any target: email, Slack, Teams, PagerDuty.

What it doesn't cover: gateway health (there is no API to query gateway online/offline status from Power BI), the distinction between a hard refresh failure and a successful refresh loading wrong data (the API doesn't expose row counts or data watermarks), and ADF or Fabric pipeline failures unless you build separate polling for those APIs as well.

Setup cost is meaningful: you need to write and maintain polling logic, handle API rate limits, set up the Azure infrastructure, and extend the solution each time you add a new integration. This approach is chosen by teams with engineering bandwidth who want control over the alerting stack. It's the right choice if you're already invested in Azure Monitor for other infrastructure monitoring and want Power BI as one more source in the same system.

Power Automate has a built-in connector for Power BI that includes a trigger: "When a dataset refresh fails." You can build a flow in minutes that fires on any refresh failure and sends a message to Teams, an email, or a webhook.

What it covers: refresh failures across all workspaces the flow owner has access to — this is the key advantage over built-in notifications. A single Power Automate flow can monitor multiple workspaces and route notifications to Teams channels, email groups, or webhooks. The trigger fires on failure; the flow body can look up the dataset name and workspace and include them in the message.

What it doesn't cover: the error code is not available from the Power Automate trigger (you need a separate REST API call to get the detailed error); gateway health is not surfaced; silent failures are not detected; ADF or Fabric pipeline failures require separate flows with different connectors; and Power Automate has its own reliability considerations — a failed flow doesn't send a notification about the failed flow.

Power Automate is a good middle step for teams that want coverage across multiple workspaces without the engineering investment of a custom REST API solution. The limitation is depth: you'll know a refresh failed, but getting the error code requires an additional step, and getting upstream pipeline context requires a separate flow connecting the Power BI trigger to an ADF API call.

Dedicated data observability and monitoring tools — MetricSign and comparable products — connect to Power BI, ADF, Fabric, Databricks, dbt, and other parts of the stack through their respective APIs and combine the signals into a single incident feed.

What they cover: refresh failures with error codes, gateway health, silent failures (via volume checks and watermark monitoring), upstream pipeline failures, cross-stack lineage, alert routing to Teams, Slack, email, or webhook, and consolidated visibility across all workspaces without per-dataset configuration.

What they require: a connection to your Power BI tenant (via service principal or admin API), and potentially connections to ADF, Fabric, or other tools if you want cross-stack coverage. For Power BI specifically, read access to the admin API or to individual workspaces is sufficient.

The core advantage over the other three options is context. When an alert fires, it includes not just that a refresh failed, but what the error was, which gateway was involved, whether the upstream ADF pipeline succeeded, and which other reports are currently serving stale data. That context is what reduces time-to-resolution from 90 minutes to ten.

The built-in notification is sufficient if you have fewer than five datasets, one workspace, and an engineer who is always available by email during business hours. It requires no setup, catches hard failures, and is better than nothing.

Power Automate is a good fit for teams that want multi-workspace coverage and can accept some limitations on error detail. It's low-cost to build and doesn't require engineering infrastructure beyond a Power Automate license.

Azure Monitor with REST API polling is appropriate when you already have Azure Monitor as the central monitoring tool for your infrastructure and want Power BI as one more source. Budget for ongoing maintenance as the Power BI API evolves.

A dedicated monitoring tool is the right choice when: you have more than ten datasets across multiple workspaces; you have upstream pipelines in ADF, Fabric, or other tools that also need monitoring; you want to detect silent failures, not just hard failures; or you want a consolidated view and on-call routing without building and maintaining custom infrastructure.

Most teams start with built-in notifications and move to a dedicated tool when the limitations start causing incidents — usually after the first time a user finds a problem before the monitoring did.

The tool you choose matters less than what the alerts it sends actually say. A well-designed refresh failure alert includes six things: the dataset name and workspace, the exact time of failure, the error code (not just "refresh failed"), the last successful refresh time, the gateway involved if applicable, and the affected reports if lineage is available.

With that information, an engineer can start the fix without opening Power BI Service, the gateway console, or any other tool to establish basic facts. Without it, every alert is a starting point for an investigation that shouldn't have to happen before the actual work begins.

MetricSign formats alerts to include all six fields by default. For built-in Power BI notifications and basic Power Automate flows, you'll need to add the REST API call to retrieve error details and construct the message yourself.