Nearly every failing scheduled refresh comes down to one of four causes, and they are worth checking in this order: credentials that have expired or belong to somebody who left, a gateway that is offline or out of date, a data source that changed shape underneath the report, or a refresh that ran out of time. The error message usually points at the right one, once you know what each looks like. The fix for the first three is typically minutes to hours of work. The fourth can mean the model needs restructuring, which is a bigger conversation.
What matters more than any single failure is whether anyone finds out. A refresh that fails loudly is an inconvenience. A refresh that fails quietly puts last month's numbers in this month's board pack, and nobody in the room knows.
What actually causes a Power BI refresh to fail?
Here are the four causes, how each one usually shows up, and what fixing it involves. There are rarer ones, but if your refresh has started failing and nothing else obviously changed, work down this list.
| Cause | How it usually shows up | What fixing it involves | How you stop it recurring |
|---|---|---|---|
| Expired or orphaned credentials | "Credentials are invalid" or an authentication error, often right after a password change or a leaver | Re-entering credentials in the semantic model's data source settings | Service accounts for refresh, not a person's login |
| Gateway offline or outdated | "Unable to connect" or gateway unreachable errors on on-premises sources | Restarting or updating the gateway on the machine that hosts it | A named gateway owner, updates applied, and not hosting it on someone's desktop PC |
| Source changed shape | "Column not found", a missing field error, or a moved or renamed file | Repointing the query, or updating steps that reference the old structure | Change control on sources the reports depend on, and telling whoever owns the report |
| Timeout | Refresh runs for hours then dies, often intermittently | Reducing what gets loaded: remove unused columns, fix the model shape, consider incremental refresh | A model built to load what the reports actually need, not the whole source |
The first cause is the most common and the most human. Refresh credentials are very often a real person's login, because that is who set the report up. That person changes their password, or leaves the company and has their account disabled, and every refresh that depended on their credentials fails the same day. It is a five minute fix and a recurring one until somebody moves the refresh onto a service account.
Gateways fail for mundane reasons. The machine running the gateway got rebooted for updates and the service did not come back. The gateway software is a year out of date. Or, a recurring pattern I have seen more than once, the gateway is installed on a desktop under somebody's desk and they switched it off before going on holiday.
Source changes are the sneaky one, because nothing failed on the Power BI side. Somebody renamed a column in a spreadsheet, moved a file to a different folder, or a system update altered a table. The refresh is doing exactly what it was told, against a source that no longer looks the way it did.
Timeouts are the one that tells you something about the build. A refresh that regularly runs close to its limit is usually loading far more data than the reports use, or transforming it in ways that should have happened further upstream. Treating the symptom (splitting the load, refreshing less often) is possible. Fixing the cause usually means revisiting the model, which is one of the things a health check scores.
What are the actual limits on Power BI refresh?
These are Microsoft's documented limits, from the Power BI data refresh documentation on learn.microsoft.com, as of August 2026. They matter because two of the four causes above interact with them.
| Limit | Shared capacity (Pro workspace) | Premium or Fabric capacity |
|---|---|---|
| Scheduled refreshes per day | 8 | 48 |
| Maximum duration of one refresh | 2 hours | 5 hours |
| Failure notification | Email to the model owner, plus any contacts configured | Same |
Two things follow from that table. First, if your refresh takes longer than two hours on a Pro workspace, it does not slow down, it dies. A model that has grown steadily for a couple of years can cross that line without anyone changing anything, which is why a refresh that "just started failing" sometimes has no trigger event at all. Second, the failure email goes to the model owner. If the owner left the company eight months ago, the failure emails are going to a disabled mailbox, which brings us to the real problem.
Why did nobody notice the numbers were stale?
A failed refresh does not blank the report. It leaves the report exactly as it was, showing the data from the last successful refresh, with no banner and no warning on the page. Everything looks normal. The only visible clue is a "last refreshed" timestamp most viewers never check.
That is why silent refresh failure is expensive in a way that has nothing to do with the fix. The fix is usually minutes. The cost is a management meeting discussing three-week-old sales figures as if they were yesterday's, decisions made on them, and the moment somebody eventually notices, which is also the moment they stop trusting every other number in the pack. Rebuilding that trust costs far more than any gateway restart.
There is a second quiet failure mode worth knowing about. On shared capacity, Microsoft pauses the refresh schedule on semantic models nobody has visited for two months, and refresh schedules that fail repeatedly eventually get switched off altogether. Both behaviours are documented, both are sensible from Microsoft's side, and both mean a report can stop updating without anyone deciding it should. A report that matters quarterly but is only opened quarterly can be paused exactly when you need it.
How do you find out why a refresh failed?
Every semantic model in the Power BI Service keeps a refresh history: open the model's settings and you get a list of recent attempts, each marked succeeded or failed, with an error message behind the failures. That message is where diagnosis starts, and it usually maps onto one of the four causes above within a minute or two of reading.
If the error points at a gateway, the next stop is the gateway itself: is the service running, is it the current version, can it reach the source? If the error points at the source, the question is what changed and who changed it. If there is no error at all and the data is still stale, check whether the schedule is actually enabled, because of the pausing behaviour above.
None of this is difficult. It is work that has to be somebody's job, and in a lot of businesses it is nobody's job, which is how failures stay silent for weeks.
How do you stop refreshes failing quietly?
Four habits, in rising order of effort.
Put the credentials on a service account. Not a person. This single change removes the most common failure cause, because service accounts do not change their passwords on a rota or hand in their notice.
Give the gateway an owner. One named person who knows it exists, keeps it updated, and knows which reports die if it goes down. Host it on a server, not a laptop.
Route failure alerts to a mailbox somebody reads. The model settings let you add contacts beyond the owner. Add a shared mailbox or the person who actually cares about the numbers, so a failure becomes a same-day conversation rather than an archaeology project.
Have somebody actually watch it. This is the gap my Care Plan exists to fill. The Watch tier is £250 a month: refresh monitoring and alerting, any failure diagnosed within 24 hours, and a scored monthly health report so you can see whether the estate is getting better or worse. It deliberately includes no build hours, because the job at this tier is making sure a failure is noticed and understood before your finance director notices it first. What the wider market charges for this kind of cover, and what the price bands actually include, is a post of its own.
The honest summary: refresh failures are cheap to fix, expensive to miss, and almost entirely preventable with a service account, an owned gateway and someone paying attention.
Common questions
Why does my Power BI refresh keep failing after a password change?
Because the refresh is using a person's login rather than a service account. When that person's password changes, every data source using their stored credentials fails until the credentials are re-entered in the semantic model's settings. Moving refresh credentials onto a dedicated service account stops this class of failure permanently.
What is a gateway and why does it break refreshes?
An on-premises data gateway is a small piece of software that lets the Power BI Service reach data that lives inside your network, like a SQL Server or a file share. If the machine hosting it is off, the service has stopped, or the software is badly out of date, every refresh that depends on it fails. The fix is usually restarting or updating it; the prevention is hosting it on a server with a named owner.
How many times a day can Power BI refresh?
On a Pro workspace (shared capacity), up to 8 scheduled refreshes a day. On Premium or Fabric capacity, up to 48. A single refresh can run for at most 2 hours on shared capacity and 5 hours on capacity, per Microsoft's documented limits as of August 2026. If you think you need more than eight refreshes a day, it is worth asking what decision actually changes hour by hour before paying for capacity.
Why did my scheduled refresh switch itself off?
Two documented behaviours cause this. On shared capacity, Microsoft pauses refresh on semantic models that nobody has opened for two months. And a schedule that fails repeatedly is eventually disabled automatically. In both cases the report quietly stops updating, so a schedule that "vanished" is usually one of these rather than a person's action.
Does a failed refresh mean my report shows wrong numbers?
It means the report shows old numbers. The report keeps displaying the data from the last successful refresh with no visible warning, which is worse than an error page, because everything looks normal. The "last refreshed" timestamp on the semantic model is the only honest witness, and almost nobody checks it.
Will anyone be alerted when a refresh fails?
By default, an email goes to the semantic model owner when a refresh fails. If the owner has left or ignores the mailbox, nobody is alerted. You can add additional contacts in the model's settings, and I would treat doing so as basic hygiene for any report a decision depends on.
What does it cost to have someone monitor Power BI refreshes?
My Watch tier is £250 a month: monitoring, alerting, failures diagnosed within 24 hours, and a scored monthly report on the estate's health, with no minimum term. Published UK support retainers more broadly run from around that point up to several thousand a month depending on what else is bundled in; the retainer cost breakdown compares the published numbers.