Refresh failures are inevitable in production Power BI environments — but silent failures are a choice. Learn how to build layered alerting, read diagnostic error messages accurately, trace failures to specific M query behavior, and execute a structured recovery workflow that keeps you in control.
It's Monday morning. Your sales director opens the regional performance dashboard at 7:45 AM before the all-hands meeting, and the numbers are three days old. The scheduled refresh that was supposed to run at 5:00 AM silently failed — no one was notified, the error was swallowed somewhere in the pipeline, and now you're the one scrambling to explain why the data your entire organization relies on is stale. This is not a hypothetical. It happens constantly in production Power BI environments, and it almost always comes down to the same root causes: inadequate alerting, no diagnostic workflow, and no recovery runbook.
Managing refresh reliability in Power BI Service is one of those skills that separates practitioners who maintain hobbyist dashboards from professionals who run production data infrastructure. A scheduled refresh is a contract between your data pipeline and your consumers. When that contract breaks — and it will break — you need to know immediately, understand exactly why, and restore service with minimum downtime. This lesson teaches you exactly that: how to configure robust alerting for refresh failures, how to read and interpret diagnostic information from the Power BI Service, how to trace failures back to the actual M query or data source, and how to build repeatable recovery workflows that make you look like you had it under control the whole time.
What you'll learn:
You should be comfortable with:
You do not need to be an M language expert. We will cover enough diagnostic M to trace failures, but the focus here is operational, not development.
Before you can diagnose failures intelligently, you need a clear mental model of what actually happens when a scheduled refresh runs. Most practitioners think of refresh as a single operation. It isn't. It's a chain of discrete steps, and failures can occur at any link.
When Power BI Service initiates a scheduled refresh, here's what actually happens:
Failures can happen at step 2 (expired credentials), step 3 (gateway offline or misconfigured), step 4 (source system unavailable, query timeout, schema change), step 5 (memory exceeded, row-level transformation error), or step 6 (DAX expression error after a schema change). The error message you see in the refresh history is your primary clue about which step failed — if you know how to read it.
Key insight: Power BI Service does not retry failed refreshes automatically. One failure means your data is stale until the next scheduled window or a manual intervention. This is why immediate alerting is non-negotiable.
You probably know how to turn on scheduled refresh. What's worth focusing on here are the less-obvious settings that influence reliability.
In Power BI Service, navigate to your semantic model's settings page (the dataset in your workspace), then expand the Scheduled refresh section.
Refresh frequency: You can schedule up to 8 times per day for shared capacity, or up to 48 times per day for Premium capacity. If you need more granular refresh, you're pushing toward streaming datasets or DirectQuery — both of which have their own trade-offs.
Time zone: This setting is deceptively important. Power BI Service stores and executes refresh schedules in UTC by default, but the UI lets you select a local time zone. If your data warehouse maintenance window runs from 2:00 AM to 4:00 AM Eastern, and you've set a refresh for 3:00 AM Eastern, you will get consistent failures during that window. Always cross-reference your refresh times against source system maintenance windows and the gateway server's own scheduled tasks.
Keep refresh failure notifications on. Under the scheduled refresh settings, there's a toggle to send failure emails to the dataset owner. Turn this on. It sounds basic, but it's frequently left disabled because someone didn't want to "get too many emails" during initial testing and forgot to re-enable it. This is your first line of defense.
Max parallel evaluations (Premium only): If you're on Premium capacity and your dataset has many tables, Power BI will attempt to refresh tables in parallel. This can be great for performance but can also overwhelm source systems with concurrent connections. If you're seeing intermittent failures that look like connection timeouts, consider whether your source system can handle the concurrency.
After you configure refresh, go to the Refresh history tab immediately and run a manual refresh. This validates credentials, gateway connectivity, and source availability before you rely on automation. There's no worse time to discover a configuration problem than during the first scheduled run at 5:00 AM.
Relying on a single alerting mechanism is like relying on a single backup. You want layers. Here are three complementary approaches, each catching what the others might miss.
This is the baseline. In the scheduled refresh settings for your semantic model, ensure the dataset owner account receives failure notifications. The email arrives within a few minutes of the failure and includes the time, a high-level error category, and a link back to the dataset.
The weakness of this approach is that it only reaches one person — the dataset owner. If that person is on vacation, or if the dataset was published by a service account that no one actively monitors, the email goes nowhere useful.
To broaden coverage, you can add co-owners or use a distribution list as the dataset contact. Under Settings > Contact list for the semantic model, add additional users or an email group. These contacts receive failure notifications alongside the owner.
Power Automate has a connector for Power BI that includes a trigger called When a dataflow refresh completes — but for semantic model (dataset) refreshes, you'll use a different approach: the Power BI REST API polled by a scheduled flow.
Here's a practical pattern. Create a Power Automate flow that:
"Failed", sends a Teams message or email to your data team channel with the error details.The Power BI REST API endpoint you need is:
GET https://api.powerbi.com/v1.0/myorg/groups/{groupId}/datasets/{datasetId}/refreshes?$top=1
This returns the most recent refresh record. The response JSON looks like this:
{
"value": [
{
"requestId": "a1b2c3d4-...",
"id": 42,
"refreshType": "Scheduled",
"startTime": "2024-11-18T05:00:12.347Z",
"endTime": "2024-11-18T05:23:41.892Z",
"status": "Failed",
"serviceExceptionJson": "{\"errorCode\":\"DM_GWPipeline_Gateway_DataSourceError\",\"pbiErrorCode\":\"DM_GWPipeline_Gateway_DataSourceError\",\"errorDescription\":\"OLE DB or ODBC error: [DataSource.Error] Timeout expired...\"}"
}
]
}
In your Power Automate flow, parse the serviceExceptionJson field — it's a JSON string embedded in a JSON object, so you'll need a second Parse JSON action — and extract the errorDescription. Include this in your notification so the on-call person immediately knows whether they're dealing with a gateway issue, a credential problem, or a query timeout. The difference in response action is significant.
To authenticate the API call from Power Automate, use the Power BI connector's Run a query against a dataset action for simpler scenarios, or configure an HTTP action with an Azure AD service principal for production-grade flows.
Tip: Store your
groupIdanddatasetIdas environment variables in your Power Automate solution. These GUIDs are available in the URL when you navigate to your dataset in Power BI Service. Using variables instead of hardcoding makes your flow portable and easier to maintain.
Sometimes a refresh technically succeeds but produces wrong data — an upstream table was truncated, a key column returned nulls, or row counts dropped by 90%. A successful refresh status won't catch this. Data Activator (formerly known by its codename "Reflex") in Microsoft Fabric can watch for data conditions and fire alerts when those conditions are met.
If your workspace is in Fabric, connect a Data Activator item to your semantic model and define a trigger such as:
FactSales drops below 50,000 (your known minimum for a healthy daily load)LastUpdated timestamp column in your DimRefreshLog table is more than 25 hours old[Data Freshness Hours] exceeds a thresholdThis moves your alerting from process-level (did the refresh run?) to data-level (is the data actually good?). These are fundamentally different questions, and both matter.
When a refresh fails, your first stop is the Refresh history page for your semantic model. You can reach it from the dataset's context menu in the workspace view, or from Settings > Scheduled refresh > Refresh history link.
The history table shows you start time, end time, duration, refresh type (Scheduled, Manual, API), and status. Click on a failed refresh row, and you'll see the error detail pane.
Here's how to read the error messages you'll encounter most frequently:
Error: DM_GWPipeline_Gateway_DataSourceError
Description: Unable to connect to the data source.
Check the credentials for the data source.
This almost always means one of three things: the credentials stored in Power BI Service have expired (common with organizational accounts that have password rotation policies), the service account's permissions were revoked, or someone changed the data source path (server name, database name) without updating the gateway data source configuration.
Recovery action: Navigate to the semantic model's Data source credentials settings and re-enter credentials. Then run a manual refresh to confirm.
Error: DM_GWPipeline_Gateway_GatewayNotFoundError
Description: The gateway is not available.
Check that the gateway is online and the data source is mapped correctly.
The on-premises data gateway service on the host machine is not running, the machine itself is offline, or the gateway cluster's status in Power BI Service shows degraded. Gateway reliability is a significant operational concern — your Power BI Service SLA is bounded by the availability of your on-premises gateway host.
Recovery action: Check the gateway machine's Windows Services for the "On-premises data gateway service" — it should be running under a service account. Restart if stopped. Check the gateway logs at C:\Windows\ServiceProfiles\PBIEgwService\AppData\Local\Microsoft\On-premises data gateway\ for detailed error output.
Error: DM_GWPipeline_Gateway_DataSourceError
Description: OLE DB or ODBC error: [DataSource.Error]
Microsoft SQL: Timeout expired. The timeout period elapsed
prior to completion of the operation or the server is not responding.
This is a query execution failure — the data source responded but the query ran too long. This can indicate a performance regression in the source system (new data volume, missing index, blocking query), or it can indicate that your Power Query transformations are not folding properly and are pulling too much data through the gateway.
Error: Expression.Error
Description: The column 'RegionCode' of the table wasn't found.
This is a schema change. Someone altered a table or view in your source system and removed or renamed a column your Power Query query depends on. This is one of the most common failure modes in production environments.
Warning: Schema change errors are silent until the next refresh. If a column is renamed in your SQL Server source at 10:00 AM and your refresh doesn't run until midnight, your data is stale for 14 hours before anyone knows. This is another argument for more frequent monitoring, not just more frequent refresh.
The refresh history tells you what failed at a high level. Finding where in your M code the failure originated requires a bit more digging.
If you've received an error that's traceable to a specific query or transformation, reproduce the failure in Power BI Desktop before attempting repair. Open the .pbix file, then in Power Query Editor, go to Tools > Diagnostics > Start Diagnostics before clicking Refresh Preview. This generates a diagnostics table that captures every evaluation step, its duration, and whether it produced an error.
After the error occurs, go to Tools > Diagnostics > Stop Diagnostics and examine the generated Diagnostics.Detailed query. Filter the Category column for "Error" to jump directly to the failing steps.
One of the most powerful things you can check when troubleshooting timeouts is query folding. In Power Query Editor, right-click any step in the Applied Steps pane. If the option View Native Query is available and not grayed out, that step is folding to the data source — the transformation is being executed by the source system's query engine rather than the Power Query engine. This is almost always what you want.
If View Native Query is grayed out, that step and all subsequent steps are running in-process in the Mashup engine, meaning all data up to that point has been pulled through the network first. For large tables, this is catastrophic for performance and is a common cause of timeout failures.
A typical scenario: you have a SQL Server table with 50 million rows. Your M query does this:
let
Source = Sql.Database("prod-sql-01", "SalesDB"),
SalesTable = Source{[Schema="dbo", Item="FactSales"]}[Data],
// This step folds — filtered at the source
Filtered = Table.SelectRows(SalesTable, each [SaleDate] >= #date(2023, 1, 1)),
// This step also folds — SQL handles the column selection
Selected = Table.SelectColumns(Filtered, {"SaleID", "CustomerID", "SaleDate", "Amount", "RegionCode"}),
// THIS step breaks folding — Text.Upper is not native SQL
Transformed = Table.TransformColumns(Selected, {{"RegionCode", Text.Upper}})
in
Transformed
The Text.Upper function has no SQL equivalent, so folding breaks at Transformed. Power Query pulls all rows from Selected across the network and then applies the transformation locally. If Selected returns 10 million rows, you're transferring a large volume of data through the gateway just to capitalize a column.
The fix here is to either push the transformation into the SQL view/stored procedure at the source, or restructure your M to minimize rows before the folding break:
let
Source = Sql.Database("prod-sql-01", "SalesDB"),
// Push as much filtering as possible before the fold break
SalesTable = Source{[Schema="dbo", Item="FactSales"]}[Data],
Filtered = Table.SelectRows(SalesTable, each [SaleDate] >= #date(2023, 1, 1)),
Selected = Table.SelectColumns(Filtered, {"SaleID", "CustomerID", "SaleDate", "Amount", "RegionCode"}),
// Consider whether this transformation is truly necessary in Power Query
// Or better: create a computed column in the SQL view: UPPER(RegionCode) AS RegionCode
Transformed = Table.TransformColumns(Selected, {{"RegionCode", Text.Upper}})
in
Transformed
Tip: The Power Query formula
Table.Viewand theValue.NativeQueryfunction are advanced tools for forcing native SQL execution when the automatic folding detection fails. They're worth knowing about for complex scenarios.
When a dataset has 20 tables and the error message is generic, you need to figure out which table triggered the failure. Here's a practical debugging approach.
In Power BI Desktop, open Power Query Editor. Temporarily disable all queries except one by right-clicking each query and unchecking Enable Load. Start with tables you suspect (large fact tables, tables from problematic sources). Click Close & Apply and see if the refresh succeeds. Methodically re-enable tables until you find the failing one. This binary search approach is faster than reading log files when you have many tables.
When a refresh fails in production, you need a structured process — not because you can't improvise, but because you'll be dealing with stakeholder pressure, time constraints, and incomplete information. A written workflow lets you stay systematic under stress.
Here is a practical incident recovery workflow for Power BI refresh failures. Adapt this to your organization.
For credential errors:
For gateway errors:
For query timeout errors:
Sql.Database("server", "db", [CommandTimeout=#duration(0, 2, 0, 0)]) (this sets a 2-hour timeout, use with caution)For schema change errors (column not found):
// Defensive column check before transformation
let
Source = Sql.Database("prod-sql-01", "SalesDB"),
SalesTable = Source{[Schema="dbo", Item="FactSales"]}[Data],
// Add a safety check for columns that might be renamed
ColumnNames = Table.ColumnNames(SalesTable),
HasRegionCode = List.Contains(ColumnNames, "RegionCode"),
HasRegion = List.Contains(ColumnNames, "Region"),
// Use whichever column exists, or raise a clear error
RegionColumnName = if HasRegionCode then "RegionCode"
else if HasRegion then "Region"
else error "Neither RegionCode nor Region column found in FactSales",
RenamedTable = Table.RenameColumns(SalesTable, {{RegionColumnName, "RegionCode"}})
in
RenamedTable
This won't prevent the failure, but it gives you a cleaner error message and a single place to update when the source schema changes.
After applying the fix, do not just run a manual refresh and walk away. Validate that the data is actually correct:
MAX date in your fact table matches today's expected data.Warning: A successful refresh status in Power BI Service means the data loaded without errors — it does not mean the data is correct. Validation is a separate step that requires domain knowledge.
This is the step most practitioners skip, and it's the reason the same failures recur. After you've resolved the incident, spend 15 minutes documenting:
Keep this in a shared location (Confluence page, SharePoint document, Teams wiki tab). After six months, you'll have a playbook that makes new team members effective immediately.
This exercise gives you practice with the complete failure detection and recovery workflow using a dataset you build yourself.
Scenario: You're a data engineer at a regional logistics company. You have a Power BI dataset that connects to a SQL Server database tracking shipment statuses. The dataset refreshes daily at 6:00 AM. You need to configure alerting, simulate a failure, and practice the recovery workflow.
Step 1: Build the base dataset
In Power BI Desktop, create a new report and connect to a SQL Server source (or substitute a CSV file if you don't have SQL Server available). Create a Power Query query that:
let
Source = Sql.Database("your-server", "LogisticsDB"),
Shipments = Source{[Schema="dbo", Item="Shipments"]}[Data],
FilteredRows = Table.SelectRows(Shipments, each [ShipDate] >= Date.AddDays(DateTime.Date(DateTime.LocalNow()), -90)),
SelectedColumns = Table.SelectColumns(FilteredRows,
{"ShipmentID", "CustomerID", "ShipDate", "Status", "DestinationCity", "CarrierCode", "WeightKg"})
in
SelectedColumns
If using a CSV substitute, replicate a similar transformation structure. The specific data source matters less than going through the workflow.
Step 2: Publish and configure refresh
Publish the report to a workspace in Power BI Service. Configure a data gateway connection if needed. Set a scheduled refresh time. Navigate to Settings and enable the failure notification email for the dataset owner. Take note of the dataset's URL — extract the groupId and datasetId GUIDs from it.
Step 3: Simulate a failure
In the Data source credentials section for your dataset, intentionally enter wrong credentials (wrong password). Run a manual refresh. Observe the failure in Refresh history. Record the exact error message and error code.
Step 4: Build the Power Automate alert
Create a Power Automate flow that:
"Failed"serviceExceptionJson contentRun the flow manually to test it. Confirm you receive the alert with meaningful content.
Step 5: Recover and validate
Correct the credentials in the dataset settings. Run a manual refresh. Confirm success in refresh history. Check the row count and maximum date in the data using the dataset's Explore view or a quick measure in the report.
Step 6: Document the incident
Write a three-paragraph post-incident summary: what happened, what you did to fix it, and what you'd do differently to prevent recurrence.
A refresh completing without errors means the M queries ran without exceptions. It does not mean the source data was correct, complete, or current. Source systems can have their own ETL failures that result in empty tables or stale records — and Power BI will happily load that empty or stale data and report a successful refresh. Build data quality checks into your validation step.
When you update a connection string in Power BI Desktop (changing a server name, for example) and republish, the semantic model in Power BI Service may lose its gateway data source mapping. The dataset settings will show an unmapped source with a yellow warning icon. This causes an immediate failure on the next refresh but can be hard to spot if you're not specifically checking after republishing. Always verify gateway mappings after republishing a dataset with connection changes.
A very common pattern is using DateTime.LocalNow() or DateTime.FixedLocalNow() in M to calculate rolling date windows. Be aware that the timezone for these functions in Power BI Service is UTC — not your local timezone. If your business logic requires rolling 90-day windows based on Eastern Time, you need to account for the UTC offset explicitly:
// Timezone-aware rolling window
let
UTCNow = DateTimeZone.UtcNow(),
// Convert to Eastern Time (UTC-5 standard, UTC-4 daylight)
EasternOffset = #duration(0, -5, 0, 0),
EasternNow = DateTimeZone.SwitchZone(UTCNow, -5),
EasternDate = DateTime.Date(DateTimeZone.RemoveZone(EasternNow)),
StartDate = Date.AddDays(EasternDate, -90)
in
StartDate
On Premium capacity, you can refresh up to 48 times per day — once every 30 minutes. Just because you can doesn't mean you should. Each refresh creates load on your data source. If your SQL Server source has eight Power BI datasets all refreshing every 30 minutes, you'll eventually see cascading timeout failures as the source becomes overwhelmed with concurrent connections. Map your refresh frequency to your actual business need for data freshness, and coordinate with your database administrators.
The error message in Power BI Service refresh history is often truncated or high-level. The gateway logs contain the full stack trace and the complete error from the source system. If you're stuck on a cryptic error that doesn't make sense from the Power BI UI, go to the gateway machine and read the actual logs. They're text files in the path mentioned earlier, and they contain far more diagnostic detail than anything surfaced in the UI.
The dataset owner email is a single point of failure for your alerting. People go on vacation. Service accounts don't read email. Build your Power Automate flow to send to a team channel, not just an individual. Configure the Contact list on the semantic model to include a distribution group, not just a single user.
Refresh reliability is not glamorous, but it's the foundation that makes everything else in your Power BI implementation trustworthy. The skills you've built in this lesson cover the full operational loop: configuring refresh properly, catching failures fast with layered alerting, reading diagnostic output accurately to understand root cause, tracing failures to specific M query behavior, and executing a structured recovery workflow rather than firefighting.
The key mental model to carry forward is that refresh is a chain, and each link can break independently. Your alerting catches that the chain broke. Your diagnostic skills identify which link. Your recovery workflow fixes it systematically. Your post-incident documentation prevents the same link from breaking the same way twice.
To deepen this skill set, explore:
The operational discipline you build around refresh management scales directly into broader data engineering practices — pipeline monitoring, SLA management, and incident response — which are increasingly expected competencies for senior Power BI practitioners and data engineers working in the Microsoft ecosystem.