Skip to content
Power BI

Why Power BI Refresh Fails, and How to Stop It

Refresh failures are almost never about the data. They are about credentials, privacy levels, gateway topology and query folding — in roughly that order.

Rajiv KumarMarch 11, 20266 min read

A dataset that refreshes on your machine and fails in the service is failing for a structural reason, not a random one. This walks the five causes that account for most of them, and what to check for each.

Scheduled refresh is where a Power BI report stops being a desktop artefact and becomes a service someone depends on. It is also where most of the operational pain lives, and the pain is remarkably repetitive: the same five causes account for the large majority of failures.

The reason they feel mysterious is that Power BI Desktop and the Power BI service do not run the query the same way. Desktop runs it as you, on your machine, with your credentials and your file system. The service runs it as a stored credential, in a shared environment, possibly through a gateway, with no access to anything on your laptop. Every one of the failures below is a consequence of that gap.

1. Credentials the service does not have

Desktop remembers a credential per source in your local settings. The service stores credentials per data source on the dataset. They are unrelated. Publishing does not carry your credential with the file.

Two specific traps:

  • The connection string changed. A server name typed as sql01 in one query and sql01.contoso.com in another produces two data sources in the service. You configure one, and the other has never been set.
  • The authentication method differs. A source you connect to interactively with your own account will need a service principal, a stored account or a gateway credential in the service — and if that identity does not have the same permissions, the refresh fails with an access error rather than a credential error.

Check the dataset's data source credentials before anything else. It is the highest-yield thirty seconds available.

2. Privacy levels blocking a fold

This is the one that produces the most baffling message — a formula-firewall error referring to a query you did not write.

Power Query's privacy levels stop data from one source being passed into a query against another. If a query filters a SQL table using values that came from a file, Power Query cannot fold that filter into the SQL statement without sending file-derived values to the database. When privacy levels forbid that, it refuses.

The proper fixes, in order of preference:

  1. Restructure the query so that the two sources are combined after each has been loaded independently, rather than one parameterising the other.
  2. Set matching privacy levels on the data sources where the organisational policy genuinely permits it.
  3. Only then consider disabling privacy-level checks — and understand that you are turning off a data-leak protection, not a nuisance dialog.

3. Gateway topology

Any source that is not reachable from the public internet needs an on-premises data gateway. The failures here are structural:

  • The data source is not defined on the gateway. A gateway can be online and healthy and still not serve a dataset whose source has no matching gateway data source definition. The connection details must match exactly — including how the server is named.
  • The dataset is not mapped to the gateway. Definition and mapping are two separate steps.
  • The gateway machine is the wrong machine. A gateway installed on a laptop that sleeps is a scheduled failure with extra steps. It belongs on a server that is always on, sized for the work, and part of a cluster if the reports matter.
  • Personal mode. Personal gateway mode runs as one person, on one machine, and is not a shared service. It is fine for a prototype and wrong for anything a team depends on.

4. Query folding that stopped folding

Query folding is Power Query pushing your transformations down into the source as a single query. When it folds, the database does the work and returns a small result. When it does not, Power Query pulls everything and does the work in memory.

A refresh that used to take two minutes and now takes forty has usually stopped folding. The usual causes are a step that has no source equivalent — an added index column, a custom function, certain merges — placed before the steps that could have folded.

The practical rule: do the filtering and column removal first, in steps that fold, and put anything exotic at the end. In the query editor you can check whether a step still folds by looking at whether the native query option is available at that step; the first step where it disappears is where folding stopped.

The same discipline reduces cost dramatically. Filtering three years of history down to the eighteen months the report actually shows, at the source, is often the entire performance fix.

5. Timeouts and capacity

Refresh has limits, and they differ between shared capacity and dedicated capacity. Rather than quoting numbers that change, treat a consistent timeout as a design signal rather than a configuration problem:

  • Incremental refresh is the structural answer for large fact tables. Partition by date, refresh the recent window, leave history alone. It requires a well-formed date filter that folds — which brings you back to the previous section.
  • Move transformation upstream. A view, a stored procedure or a warehouse table doing the heavy shaping is almost always faster than Power Query doing it.
  • Split the model. One dataset trying to serve six unrelated reports refreshes for all of them every time.

Diagnosing in the right order

OrderCheckWhat it rules out
1Refresh history — read the actual error, not the summaryGuessing
2Data source credentials on the datasetThe most common cause
3Gateway status and data source mappingEverything on-premises
4Whether the failure mentions the formula firewallPrivacy levels
5Duration trend across recent refreshesFolding regressions and growth
6Whether it succeeds in Desktop with the same credential the service usesPermission differences between identities

Common mistakes

  • Reading only the summary error. The detail in refresh history usually names the query and the source. Open it.
  • Testing in Desktop as yourself. That proves the query works for you, which was never in doubt. Test with the identity the service uses.
  • Turning off privacy levels as a first move. It makes the error disappear and the data-leak risk real.
  • Putting the gateway on a workstation. Refresh then depends on someone not shutting their machine.
  • Adding an index column early. One of the most common accidental folding-breakers.
  • Refreshing eight times a day because it is cheap. Refresh frequency should follow how often the data actually changes.

Frequently asked questions

Why does refresh work in Desktop but fail in the service?

Because they run as different identities, from different machines, with different network access. Any file path, local database or interactively-authenticated source that Desktop can reach is not automatically reachable from the service.

Do I need a gateway for a cloud data source?

Generally no — a source the service can reach over the internet needs no gateway. A cloud database restricted by firewall or private endpoint may still need one, because the restriction is what makes it unreachable, not where it is hosted.

What is the difference between the two gateway modes?

Standard mode is a shared service: several datasets and several people use one gateway, and data sources are administered on it. Personal mode runs for one user only and cannot be shared. Anything with more than one stakeholder wants standard mode.

How do I tell whether my query folds?

In the Power Query editor, right-click a step and look for the option to view the native query. Where it is available, the query folds up to that point; the first step where it greys out is where folding stops.

Will incremental refresh fix a slow refresh on its own?

Only if the range filter folds to the source. Incremental refresh over a query that does not fold still pulls everything, and you have added complexity without removing work.

The habit worth building

Treat refresh as part of the design, not as an operational afterthought. Decide early where the transformation happens, which identity does the reading, and how much history the report genuinely needs. Datasets designed with those three answers in mind rarely produce the failures above — and when they do, the cause is usually obvious within a minute.

Share