How to Configure Scheduled Refresh in Power BI Without Getting Burned

Most Power BI problems we get called about are not really Power BI problems. Someone publishes a report, it looks great in the demo, everyone claps, and then two weeks later a manager quietly stops opening it because the numbers never seem to match what she is seeing in the source system. Nine times out of ten the report is fine. What broke is scheduled refresh, or more precisely, it was never set up properly in the first place.

Scheduled refresh is the setting that tells the Power BI service to go back to your data source on a timer, pull the latest data, and update the published copy of your model. For import mode reports, which is the vast majority of what gets built in Australia, this is the only thing keeping your report current. Publish once and never configure refresh, and your dashboard is a photograph of the day you hit publish. It will happily show that photograph forever while the business moves on around it.

I want to walk through how to actually set this up, because the Microsoft documentation on configuring scheduled refresh covers the buttons but not the judgement calls. The buttons are easy. Knowing what to click and why is where people come unstuck.

Where the setting lives and how to find it

Scheduled refresh is a property of the semantic model, not the report. This trips people up constantly. You do not configure refresh on the report you built. You configure it on the underlying dataset that the report sits on top of. In the Power BI service, go to the workspace, find the semantic model in the list, and open its settings. There you will see a section for scheduled refresh with a toggle and a set of options underneath.

The reason this matters: one semantic model can feed several reports. Set refresh once on the model and every report built on it stays current. If you have three reports all pointing at the same model, you do not configure refresh three times. You configure it once, on the model. I mention this because I have watched people hunt through report settings looking for a refresh option that is not there, then conclude Power BI is broken. It is not. You are just in the wrong place.

The data source credentials come first

Before scheduled refresh will do anything, Power BI needs to know how to authenticate to your source. This is the data source credentials section, and it is the number one reason a freshly configured refresh fails on its first run. You set up the schedule, feel pleased with yourself, and the next morning there is a red error because the service tried to connect to your SQL database and had no valid credentials to do it with.

Sort the credentials before you touch the schedule. If your source is a cloud service like Azure SQL, Dataverse or a SaaS connector, the service can usually reach it directly and you authenticate right there in the settings. If your source is on-premises, so an on-site SQL Server, a file on a network share, or an ERP living in your own data centre, you need an on-premises data gateway configured and the credentials bound to that gateway connection. No gateway, no refresh, no exceptions for on-prem sources. We cover the gateway side of this in more depth as part of our Power BI consulting work, because it is the piece that most in-house teams have not set up on proper infrastructure.

Setting the cadence, and the time zone that catches everyone

Once credentials are sorted, you set the frequency. Daily or weekly, then you add specific times of day when the refresh should run. This is where I see the most avoidable mistakes.

First, the time zone. The refresh schedule has its own time zone setting, and it defaults to something that is often not yours. I have seen an Adelaide business set a refresh for "8am" only to have it run at 8am UTC, which is the middle of the afternoon here, hours after the morning meeting where everyone wanted the fresh numbers. Set the time zone explicitly to Australian Eastern, Central or Western time depending on where your users are. Do not assume it knows. It does not.

Second, match the cadence to how often your data actually changes. This is the discipline most people skip. If the data behind your report comes from an overnight batch job that finishes at 2am, then one refresh at, say, 5am is all you need. Scheduling eight refreshes through the day just hammers your source system to reload data that has not changed since the small hours. Every refresh is real load on your database, real work for your gateway, and a window where the model might be locked. More refreshes is not more freshness. It is more cost and more risk for zero benefit if the underlying data is static.

Third, and people forget this, add a buffer after your data lands. If your ETL finishes at 2am, do not schedule the refresh at 2am. Schedule it at 2:30 or 3am. Batch jobs run long. If your refresh kicks off before the data has fully landed, you refresh into half-loaded tables and get numbers that are wrong in a way nobody notices until it causes an argument in a meeting.

Refresh limits depend on your licence

This one bites businesses that grow into Power BI. On shared capacity, which is standard Power BI Pro, you are capped at eight scheduled refreshes per day per model. On a Premium or Fabric capacity, that jumps to forty eight, which is effectively every half hour if you want it.

Eight sounds generous until you have an operations team watching a live dashboard and asking why it only updates a few times a day. If your data genuinely changes through the day and people need to see it, eight refreshes may not be enough and you are looking at either a capacity upgrade or a rethink using DirectQuery for the parts that need to be live. But be honest about whether you actually need it. Most reporting does not. A sales dashboard that people check each morning is perfectly served by a single early refresh. Do not buy Premium to solve a problem you do not have. Work out what the business genuinely needs first, which is exactly the sort of thing our business intelligence work starts with before anyone talks about licences.

Failure notifications, or how not to find out from your boss

When a scheduled refresh fails, Power BI sends an email. By default it goes to the semantic model owner. Here is the problem: the model owner is usually the analyst who built it, and analysts move teams, go on leave, and change roles. Six months later the failure notice is landing in the inbox of someone who left, and nobody knows the report has been quietly serving stale data for a fortnight.

Fix this on day one. In the scheduled refresh settings you can add extra recipients for failure notifications. Point them at a monitored shared mailbox or a team distribution list, not one individual. If a refresh fails, you want it to hit a place where at least one human is guaranteed to see it. This single setting change has saved more than one client from the embarrassment of a director noticing stale numbers before the data team did.

Why refreshes fail, so you know what you are looking at

When you do get a failure, the usual suspects are worth knowing. Expired credentials are the big one, especially with OAuth sources where the token times out and needs re-authorising, or when someone rotates a database password and forgets the refresh depended on it. Schema changes are next: a column gets renamed in the source and the refresh breaks because the model is looking for a field that no longer exists. Timeouts happen on large models that run past the two hour limit on shared capacity. And the gateway being offline, which for on-prem sources is a perennial favourite.

The pattern across all of these is that the report itself did not change. The world around it did. Which is why we treat refresh as an operational concern, not a one-off setup step. A report that matters needs someone occasionally checking the refresh history, the same way you would check that any production job is still running. It takes two minutes and it is the difference between catching a problem quietly and having it surface in front of the people you least want to see it.

The short version

Configure refresh on the semantic model, not the report. Sort credentials before you set a schedule or the first run will fail. Set the time zone explicitly to your actual time zone. Match the cadence to how often the data genuinely changes rather than maxing it out. Add a buffer after your data lands. Know your licence limits before you promise anyone half-hourly numbers. And point failure notifications at a mailbox a human actually reads.

None of this is hard. It is just the unglamorous part that gets skipped when everyone is excited about the visuals. If you have Power BI reports that people have quietly stopped trusting, the fix is almost always here in the refresh settings rather than the report itself. If you want a hand getting your reporting to stay current without someone babysitting it, get in touch and we will take a look at where things are leaking.