Data Refresh in Power BI - How to Keep Your Reports From Quietly Going Stale

The fastest way to lose trust in a Power BI report is for someone to open it on a Monday morning and see Friday's numbers. Once that happens, they stop trusting every number on the page, even the ones that were fine. And here is the frustrating part: the report itself is usually perfect. The visuals are right, the model is right, the calculations are right. The thing that broke is the least glamorous part of the whole setup, which is data refresh. The pipe that pulls fresh data in from wherever it lives and pushes it into the report so the numbers reflect reality instead of some frozen moment days ago.

I have seen data refresh sink more Power BI rollouts than bad DAX ever has. It is the plumbing, and like all plumbing, nobody thinks about it until it leaks. So let me walk through how it actually works, where it tends to go wrong for Australian businesses, and what we do to keep it boring in the good way. Microsoft's reference is Data refresh in Power BI, which is worth a read, but the doc will not tell you which bits bite people in practice. That is what I want to cover.

What refresh actually means

When you build a report in Power BI Desktop and publish it, the data comes along for the ride. That published copy is a snapshot. It reflects whatever the source held at the moment you hit refresh in Desktop. Left alone, it never changes. Refresh is the process that goes back to the source, pulls the current data, and updates that snapshot so the report keeps pace with the real world.

There are a few flavours of refresh and the names get muddled, so it helps to be precise. Data refresh is the one people mean most of the time: reload the underlying data. There is also schema refresh, which picks up new columns or tables from the source, and tile refresh, which updates the cached tiles on a dashboard. For day to day purposes, when someone says "the report is not refreshing" they almost always mean the data. The numbers are old.

The other thing worth understanding up front is the difference between import mode and DirectQuery. In import mode, Power BI keeps its own copy of the data in memory and refresh is what reloads that copy. It is fast to view because everything is already in the model, but it goes stale between refreshes. In DirectQuery, Power BI holds no copy and queries the source live every time someone interacts with the report, so the data is always current but the report is only ever as quick as the underlying database. Most reports we build are import mode, which means scheduled refresh matters enormously. Get the schedule wrong and you have a fast report full of old numbers.

The gateway is where it usually breaks

Here is the single biggest thing that trips people up. If your data lives somewhere the Power BI service cannot reach on its own, and that includes an on-premises SQL Server, a file on a network share, an ERP sitting in your own data centre, then Power BI needs a bridge to get to it. That bridge is the on-premises data gateway. It is a small piece of software that runs on a machine inside your network and shuttles data securely between the source and the cloud service.

The gateway is essential and it is also the flakiest link in the chain, because it depends on a machine staying on, staying patched, and staying connected. We have been called into more than one situation where reports mysteriously stopped refreshing, and the culprit was a gateway installed on someone's desktop that got turned off when they went on leave, or a server that was rebooted for Windows updates and never brought the gateway service back cleanly. The gateway itself worked fine. The environment around it did not.

If you are running a gateway, put it on a proper server, not a workstation. Use the standard mode gateway rather than personal mode so more than one person can rely on it. Keep it updated, because Microsoft ships monthly releases and an old gateway will eventually stop authenticating. And monitor it, so that when it goes down you find out before your users do. This is unglamorous infrastructure work and it is exactly the sort of thing that gets skipped in the excitement of building dashboards, then causes grief three months later. It is a chunk of what our Power BI consulting engagements end up covering, because the reporting is only half the job. The other half is making sure it keeps running without someone babysitting it.

Scheduled refresh and the limits nobody reads

For import mode reports, you set up scheduled refresh in the Power BI service. You tell it how often to refresh and at what times, it goes off and does it. Simple enough. But there are limits that catch people out, and they depend on your licence.

On shared capacity, so standard Power BI Pro, you get up to eight scheduled refreshes per day. On Premium or a Fabric capacity, that jumps to forty eight, which is effectively every half hour. Eight sounds like a lot until you have a business that trades across time zones or a sales team that wants numbers updated through the day. If the data behind a report only changes overnight from a batch job, one refresh a morning is plenty. If it is feeding an operations dashboard people watch live, eight might not cut it and you are looking at Premium or a rethink of the architecture.

The mistake I see is people cranking the refresh frequency to the maximum on the assumption that more is better. It is not. Every refresh is load on your source system, load on your gateway, and time where the report might be locked. If your data only updates once a day, refreshing eight times just hammers your database for no benefit. Match the refresh schedule to how often the data actually changes, not to how often you wish it did. Refreshing a report every hour when the source updates nightly is pure waste, and on a busy source it can slow down the systems everyone else is using.

Why refreshes fail, and what to do about it

When a scheduled refresh fails, Power BI emails the dataset owner. Fine, except the dataset owner is often the analyst who built it and has since moved teams, so the failure notice goes to an inbox nobody reads. First fix: make sure refresh failure notifications go to a monitored address or a shared mailbox, not one person who might be on holiday.

The common failure causes are worth knowing. Credentials expiring is the big one, especially with data sources that use OAuth tokens which time out and need re-authorising. Someone changes a database password and every refresh that used it dies overnight. Source schema changes are another: a column gets renamed in the source table and the refresh breaks because Power BI is looking for a field that no longer exists. Timeouts happen when the source is slow or the dataset is large and the refresh runs past the two hour limit on shared capacity. And the gateway being offline, which I have already banged on about.

The pattern in all of these is that the report is fine and the environment around it changed. Which is why we treat data refresh as an ongoing operational concern rather than a set and forget task. Reports that matter need someone keeping an eye on whether they are actually refreshing, the same way you would monitor any other production system. That mindset, treating your data and reporting as live infrastructure rather than a one off build, is a big part of how we approach AI and data for business intelligence. A dashboard is only useful if the number on it is true today, and keeping it true is a discipline, not a feature you switch on once.

Incremental refresh, the upgrade most people miss

One feature that deserves more attention than it gets is incremental refresh. By default, a refresh reloads the entire dataset every time. For a small table that is fine. For a fact table with years of history and hundreds of millions of rows, reloading the lot every night is slow, expensive and pointless, because the historical rows have not changed. Incremental refresh lets you tell Power BI to only reload the recent data, say the last few days, and leave the older partitions alone.

For any business with serious data volumes this is the difference between a refresh that finishes in minutes and one that either takes hours or times out entirely. It used to be a Premium only feature but it is more widely available now, and it is one of the first things we look at when a client's overnight refresh is running long or falling over. If your refresh window is getting tight, incremental refresh is usually the answer before you start throwing bigger capacity at the problem.

The short version

Data refresh is the least exciting part of Power BI and one of the most important. Build the best report in the world and it is worthless the moment the numbers go stale. Get the gateway on a proper server and monitor it. Match your refresh schedule to how often the data genuinely changes rather than maxing it out. Send failure alerts somewhere a human will see them. And look at incremental refresh before your overnight jobs start creaking.

If you have Power BI reports that people have quietly stopped trusting because the numbers do not keep up, the fix is almost never the report and almost always the plumbing behind it. That is fixable, and it is the sort of thing we sort out regularly. If you want a hand getting your reporting to stay current without constant hand-holding, get in touch and we will work out where your refresh is leaking.