Back to Blog

Power BI Refresh Failures - A Practical Troubleshooting Guide from the Field

October 23, 2026•10 min read•Michael Ridland

The email usually arrives around 7:30 in the morning. "The dashboard is showing yesterday's numbers again." Someone in finance or operations has opened the report before their first meeting, noticed the sales figure hasn't moved, and now the Power BI person is digging through refresh history instead of doing whatever they had planned for the day.

Refresh failures are the single most common support issue we deal with on Power BI engagements. Not the most interesting, but the most common. And the frustrating part is that most of them fall into maybe six or seven categories. Once you know the categories, you can usually diagnose a failed refresh in ten minutes rather than an afternoon.

Microsoft has a documentation page on troubleshooting refresh scenarios that lists the known problems. It's a useful reference, but it reads like a list of symptoms. What I want to do here is talk through the same ground the way we actually work through it with clients: what to check first, what the error messages really mean, and which problems are worth fixing properly versus patching.

Start with refresh history, not the report

This sounds obvious, but I've watched experienced people open the report, click around, then open Power BI Desktop and try a manual refresh on their laptop. That tells you almost nothing. Your laptop has different credentials, a different network path and often a different version of the data source driver.

Go to the semantic model settings in the service and open refresh history. You want three things:

  • The exact error text, including the activity ID and the cluster URI if you end up raising a support ticket
  • Whether the refresh failed immediately or ran for a long time before failing
  • Whether it's a scheduled refresh, an on-demand refresh, or something triggered by the API or a pipeline

That second point matters more than people think. A refresh that dies within seconds is almost always credentials, gateway connectivity or a data source that's unreachable. A refresh that runs for an hour and then fails is a timeout, a memory limit or a query that's gone bad on the source side. Different problems, different fixes.

Gateway problems - still the number one cause

If your data lives on-premises or behind a firewall, it's going through an on-premises data gateway. And gateways are where most refresh pain lives.

The patterns we see over and over:

The gateway machine was patched and rebooted, and the service didn't come back. Someone in infrastructure applies Windows updates on a Saturday night, the gateway service doesn't restart cleanly, and Monday morning every report in the organisation is stale. Set the service to automatic restart and monitor it. Better still, run a gateway cluster with at least two members so one machine going down isn't an outage.

The gateway is out of date. Microsoft releases gateway updates monthly and only supports the last six versions. We've walked into organisations running a gateway that's two years old. Things mostly work until they suddenly don't, usually when a connector changes on the service side. Put gateway updates on someone's calendar.

The data source in the gateway doesn't match the one in the model. This one catches a lot of people. Power BI matches the data source in your model to a gateway connection by server name and database name, and the match is exact. If your model says sqlprod01 and the gateway connection says sqlprod01.corp.contoso.com.au, Power BI treats them as different sources. You'll get a message about the model not being able to find a gateway connection, even though you can see the connection right there. Make them match character for character.

The gateway machine is undersized. A gateway handling a dozen large models refreshing at 6am on a two-core VM with 8GB of RAM will struggle. Gateway performance monitoring is built in now, and it's worth turning on. If CPU and memory are pinned during your refresh window, either spread the schedules out or give the machine more resources.

Credentials that quietly expired

The second big category. A refresh worked fine for six months and then stopped, and nobody changed anything. Somebody did change something, though: a password.

OAuth credentials for cloud sources like SharePoint, Dataverse or Azure SQL expire, and if the person who set them up has left or had their password reset, the token stops working. The error message will usually mention credentials or authentication, but sometimes it's vaguer than that.

My strong opinion here is that production semantic models should never refresh using a personal account. Use a service principal or a dedicated service account wherever the source supports it. I've seen a sales reporting suite for a 400-person organisation go dark because the analyst who built it went on maternity leave and IT disabled their account as part of a routine review. That's not a Power BI problem. It's an ownership problem that shows up as a Power BI problem.

While you're in there, check the privacy level settings. Combining data from sources with different privacy levels (say an Organisational SQL database with a Public web source) can cause the mashup engine to block the query entirely or fall back to very slow evaluation. Setting both to Organisational, where that's genuinely accurate, often fixes refreshes that fail with obscure formula firewall errors.

Timeouts and the two-hour wall

Scheduled refreshes on shared capacity have a two-hour limit. On Premium or Fabric capacity it's five hours. If your refresh is hitting those limits, the fix is almost never "make the limit longer".

What we usually find when a refresh takes too long:

  • The model is importing every row of a fact table going back ten years when the reports only ever look at the last three
  • Power Query steps are breaking query folding, so instead of the database doing the filtering, Power BI pulls the whole table across the network and filters it locally
  • Someone added a merge against a SharePoint list or an Excel file, which forces everything into the mashup engine

Query folding deserves its own paragraph. Right-click a step in Power Query and check whether "View Native Query" is available. If it's greyed out from some step onward, everything after that step runs in Power BI rather than at the source. One badly placed custom column or type change early in the query can turn a 3-minute refresh into a 90-minute one. We fixed a client's inventory model last year by moving a single step down the query, and refresh time dropped from just over two hours to eleven minutes.

The longer-term fix for large models is incremental refresh. Only refresh the last few days or weeks, keep the historic partitions as they are. It's well worth the setup effort for any fact table with more than a few million rows.

Memory errors on capacity

If you're on Premium or Fabric capacity, you'll eventually see errors about the model exceeding the memory limit during refresh. People are often confused because the model is, say, 4GB and the capacity allows 25GB per model.

The catch is that a full refresh needs roughly double the model's memory, because the old copy stays online for queries while the new copy is built. Then there's memory for any calculated columns and calculated tables, which get computed after the data loads. A 4GB model with a few heavy calculated tables can easily need 10GB or more at peak.

Options, roughly in the order I'd try them:

  1. Remove columns nobody uses. High-cardinality columns like GUIDs, timestamps to the second and free-text comments are the usual culprits. The VertiPaq Analyzer in DAX Studio will show you exactly which columns are eating memory.
  2. Move calculated columns upstream into Power Query or, better, into the source view.
  3. Refresh tables or partitions separately using the enhanced refresh API or XMLA endpoint rather than refreshing the whole model at once.
  4. Then, and only then, talk about a bigger capacity SKU.

Too many organisations jump straight to option 4. It's the most expensive fix and often the least necessary one.

The less common ones that still bite

A handful of scenarios come up less often but are painful when they do:

Refresh works in Desktop but fails in the service. Usually a data source that Desktop can reach but the service can't. A file path on someone's C: drive, a mapped network drive letter, a web API that only allows your office IP range. The service doesn't have your laptop's context.

Dynamic data sources. If a Power Query builds a URL or connection string at runtime (looping through pages of an API, for example), the service can't validate it ahead of time and won't schedule the refresh. The fix is usually to restructure the query using RelativePath and Query options in Web.Contents so the base URL is static.

Scheduled refresh got disabled. After four consecutive failures, Power BI turns the schedule off and emails the owner. If that owner has left, nobody gets the email. Check the schedule toggle before you start a deeper investigation.

Refresh succeeds but the data is still old. Check whether the source itself has been updated. We've spent time chasing a "refresh problem" that turned out to be an ETL job upstream that had silently failed three days earlier. Power BI refreshed perfectly, it just refreshed stale data.

What I'd set up so this stops being a fire drill

Fixing individual refresh failures is fine, but if you're getting several a month, the real issue is that nobody owns refresh health. A few things make a big difference:

  • A single list of production semantic models, who owns them, what they depend on, and when they refresh
  • Refresh schedules staggered so they're not all slamming the gateway and the source database at 6:00am
  • Failure notifications going to a shared mailbox or Teams channel, not one person's inbox
  • Service principals for production sources
  • A gateway cluster rather than a single machine

For larger estates, we often build a small monitoring report off the Power BI REST API or Fabric's capacity metrics that shows refresh durations over time. A refresh that's crept from 20 minutes to 75 minutes over three months is telling you something before it hits the timeout wall.

The honest view

Power BI refresh has improved a lot over the last few years. The error messages are better than they were, gateway monitoring is genuinely useful, and the enhanced refresh API gives you much finer control. But the gateway is still the weakest link in most setups, and the error text still sometimes points you in the wrong direction. "Data source error" can mean about fifteen different things.

If you're moving to Fabric, some of this changes. Data that's already in OneLake with Direct Lake mode doesn't need a traditional import refresh at all, which removes a whole category of problems. It introduces its own quirks around framing and fallback to DirectQuery, but that's a topic for another post.

If refresh issues are eating a chunk of your team's week, it's usually a sign the platform needs some structural work rather than more firefighting. Our Power BI consultants do a lot of exactly this sort of health check work, and for organisations heading towards Fabric, our Microsoft Fabric consultants can help plan the move so you're not carrying the same problems across. If you'd rather just talk it through, get in touch.