Why Is My Power BI Report Not Refreshing? A 2026 Troubleshooting Guide

That list has not changed much in years. What has changed is the failure modes underneath it. If you are troubleshooting in 2026 and following a guide written in 2023, you will check your gateway three times and never find the problem, because a Fabric semantic model has no gateway, and the fastest-growing cause of refresh failure we see on client estates is token expiry against a lakehouse source rather than anything to do with credentials in the traditional sense.

This guide is ordered the way we actually diagnose it: fastest checks first, then the 2026-specific causes, then the Databricks-connected failures that generic troubleshooting guides do not cover at all.

Start here: read the refresh history before changing anything

Open the semantic model or dataset settings, go to refresh history, and open the failed run. Power BI tells you which step failed and usually gives an error code. Almost every wasted hour of Power BI troubleshooting starts with someone re-entering credentials before reading this screen.

Two things to look for that people routinely miss:

• Rows and bytes processed. If the refresh reports success but the numbers are zero, nothing was retrieved. That is not a refresh problem, it is a query or parameter problem. The data source returned an empty set and Power BI faithfully loaded it.
• Which step failed. A failure in the data source step is a connection or permission problem. A failure later, during model load, is usually memory or timeout. These have completely different fixes, and the error text tells you which one you are in.

Download the refresh history as CSV if you are dealing with an intermittent failure. A pattern that is invisible in the UI, such as failures clustering at a particular hour, often becomes obvious in a spreadsheet.

The classic causes, in the order worth checking

These still account for most failures. Work down the list.

• Expired or changed credentials. The single most common cause. Someone rotated a password, an account was disabled, or a service account's permissions changed. Fix in dataset settings under data source credentials. If your organisation enforces regular password rotation on the account behind a data source, this will recur until you move to a service principal.
• Gateway offline or outdated. For any on-premises source, check the gateway service is running and the version is current. Microsoft retires older gateway versions on a rolling basis, and a gateway that worked last month can stop working after a retirement date passes with no change on your side.
• A query that already fails in Desktop. Open the .pbix, go to Transform Data, and let the preview refresh. If a step errors there, it will error in the service. This catches renamed columns, changed schemas and deleted tables.
• The data source moved. A SharePoint file relocated, a network path changed, a table was dropped or renamed during a release. The refresh is working correctly and telling you the source is gone.
• Timeout on a large model. Import-mode refreshes have time limits, and a model that grew past them will fail consistently rather than intermittently. This is the point where incremental refresh stops being optional.

What changed in 2026: Fabric semantic models have no gateway

If your dataset lives in Microsoft Fabric as a semantic model, most gateway-era troubleshooting simply does not apply. The refresh path is cloud-native, and there may be no gateway in the picture at all. Teams migrating from a classic Power BI Service workspace hit this constantly: they check gateway status, find it healthy, and conclude the problem is somewhere unknowable.

Three things to check on a Fabric semantic model instead:

• Direct Lake fallback. In Direct Lake mode, the model queries files in OneLake directly and there is no scheduled refresh to fail. If you are seeing stale data, the question is whether the underlying tables were updated, not whether a refresh ran. A model that has silently fallen back to DirectQuery behaves differently again, and performance rather than staleness is usually the first symptom.
• Capacity throttling. Fabric capacity is shared across workloads. A refresh that fails or queues during business hours but succeeds overnight is a capacity signal, not a data signal.
• Workspace identity and permissions. Fabric introduced its own identity model for source access. A model that worked under a user's credentials can fail when it is moved to a workspace whose identity has not been granted access to the source.

The 2026 failure mode nobody documents: OAuth token expiry

This is the one we now see most often on enterprise estates, and it is almost entirely absent from the troubleshooting content that ranks for this query.

Modern data sources authenticate through OAuth rather than stored credentials. That token has a lifetime. If it expires before the scheduled refresh runs, the refresh fails with a credential-shaped error even though nothing about the credentials is wrong. Re-entering them fixes it for a while, and then it breaks again, which is the tell.

What makes this a 2026 problem specifically: Conditional Access policies in Microsoft Entra ID frequently shorten session lifetimes as a security hardening measure. A policy change made by the security team, entirely reasonably and with no reference to reporting, can start breaking scheduled refreshes days later. The two events look unrelated, which is why this burns so much diagnostic time.

Signs you are in this scenario:

• The failure is intermittent rather than consistent
• Re-entering credentials fixes it temporarily
• The error mentions token refresh rather than authentication itself, such as DMTS_OAuthTokenRefreshFailedError
• Refreshes run fine when triggered manually but fail on schedule, because your interactive session has a fresh token and the scheduled run does not

The durable fix is to stop using user-based OAuth for scheduled refreshes. Move to machine-to-machine authentication with a service principal. Service principal tokens are not subject to the interactive session policies that keep expiring, which removes the entire failure class rather than deferring it.

When the source is Databricks: the connection-specific causes

Power BI connected to a Databricks lakehouse has its own failure modes, and this is where generic guides run out. Three we encounter regularly:

• Missing catalog or database parameters. Databricks job and API configurations now expect explicit, non-empty catalog and database values. Older scripts written when these could be omitted will fail, often with an error that points at the query rather than the configuration.
• Token lifetime conflicts on the Databricks side. The OAuth story above applies here with an extra layer: the Databricks-side token policy interacts with the Entra ID session policy, and the shorter of the two wins. If you have tightened either recently, that is your first suspect. Databricks support can adjust token behaviour for the Power BI integration in some cases, which is worth asking about before you rebuild anything.
• Waiting on a schedule instead of an event. This is the architectural fix rather than a patch. If your Databricks ETL finishes at an unpredictable time and your Power BI refresh is scheduled for a fixed one, you are guaranteed to sometimes refresh against yesterday's data or against a table mid-write.

The pattern we recommend: trigger the semantic model refresh from the end of your Databricks pipeline via the Power BI REST API, rather than scheduling it and hoping. The pipeline knows when the data is actually ready. Add retry-with-backoff to absorb transient token failures. This converts an entire category of "the report is stale" tickets into a non-event, and it is usually a day of work.

The European wrinkle: data residency and refresh

One cause almost no troubleshooting guide covers, and one that disproportionately affects the enterprises we work with: refresh failures caused by data residency configuration.

If your tenant, capacity or gateway is configured for one region and the data source sits in another, refreshes can fail or be blocked outright on cross-border access grounds. The error rarely says "this is a data residency problem." It presents as a connection or permission failure, and teams debug credentials for days.

Worth checking if you operate under EU data residency commitments:

• Whether the capacity region and the source region actually match
• Whether a gateway is deployed in the correct region for the source it serves
• Whether a recent tenant or capacity move changed the effective region without anyone connecting it to reporting

Incremental refresh: the fix that introduces its own bug

Incremental refresh is the right answer for large models hitting timeouts. It also introduces a specific failure that looks like a data problem: RangeStart and RangeEnd parameters evaluated in the wrong timezone.

If your source stores timestamps in UTC and your locale is CET or CEST, a partition boundary computed locally can silently miss rows, or return none at all. The refresh reports success. The data is wrong or absent. This is the "zero rows processed" case from the refresh history, and it is worth checking explicitly whenever incremental refresh is introduced in a European deployment.

The Cosmos Thrace perspective

Cosmos Thrace is a Databricks Silver Partner. We have delivered dozens of data platform implementations across Europe, many on Databricks, and Power BI sits on top of a large share of them. Two patterns repeat.

First, refresh failures are almost never a Power BI problem. They are an authentication problem, an orchestration problem or a data-quality problem that surfaces in Power BI because that is where someone finally notices. Teams that treat the refresh as the thing to fix keep fixing it. Teams that ask why the pipeline finished late, or why the token expired, stop having the problem.

Second, the scheduled refresh is a legacy pattern that survives because it is the default. Every estate we have moved to event-triggered refresh, where the pipeline signals completion rather than the report guessing, has seen this class of ticket largely disappear. It is not a big project. It is usually a day of work and it removes a recurring source of executive frustration, because stale dashboards are noticed by exactly the people you would least like to notice them.

Where to start if it is broken right now

Read the refresh history first and let the error name the failing step. Check credentials and gateway status, because they are still the most common causes and take two minutes to rule out. If the failure is intermittent and credentials keep "fixing" it, you are looking at token expiry, and the answer is a service principal rather than another round of re-entry. If your source is a lakehouse, check catalog and database parameters explicitly, and consider whether the refresh should be triggered by your pipeline instead of by the clock.

If refresh failures are a recurring theme rather than a one-off, the problem is usually architectural, and worth an afternoon of design rather than another patch.

Want a second opinion on a reporting estate that keeps going stale? Talk to our team or start with the free Databricks assessment.

If refresh failures are a symptom of a Power BI estate that grew without structure, our Power BI adoption roadmap for 2026 covers the governance and architecture decisions that prevent them.

Sources

• Microsoft Learn: Troubleshoot refresh scenarios in Power BI
• Microsoft Learn: Data refresh in Power BI
• Microsoft Learn: Incremental refresh for semantic models
• Microsoft Learn: Direct Lake in Microsoft Fabric
• Databricks documentation: Connect Power BI to Databricks
• Microsoft Learn: Conditional Access session controls in Entra ID