← All Kits · Power BI Kit

Power BI Scheduled Refresh, Gateways and Data Alerts

Michael Nocito · Updated August 2026 · Limits and behaviour checked against Microsoft's own documentation, linked at the end

This page answers the three questions that decide whether a published report stays useful: how often your data can update, what has to be installed for it to reach your sources, and how somebody gets told when a number crosses a line. The headline numbers are eight scheduled refreshes a day on shared capacity and 48 on Premium, and the gateway rule is simpler than it sounds.

What you do: check your storage mode first, because only Import mode needs a refresh at all. Then set the schedule in the semantic model's settings, add a gateway only if the source lives inside your network, and put alerts on dashboard tiles rather than reports.

The short version. Import mode refreshes on a schedule. A gateway is only for sources the cloud cannot reach. Alerts watch dashboard tiles.

Only one storage mode needs refreshing

Before the table: your report is slow to update. Is a refresh schedule even the right fix?

Only if you are in Import mode. Microsoft's own wording is blunt: only Import mode semantic models require a source data refresh, because only that type imports data. Everything else queries the source as people use the report.

Say out loud what that means for a stale number in a DirectQuery report. If nothing is imported, a refresh schedule cannot help, so a stale number is either cached visuals in an open browser or something at the source. Reload the report rather than hunting for a refresh setting that does nothing.

Eight a day, or 48

First: your stakeholder asks for hourly data. How many scheduled refreshes can you promise on a normal Pro workspace?

Eight. Power BI limits semantic models on shared capacity to eight scheduled daily refreshes, stored against the local time zone you pick on the settings page, with the quota resetting at 12:01 AM local time. On Premium capacity, Premium Per User or a Fabric capacity, the limit is 48.

Three practical notes on top of that. A manual Refresh now does not count against the eight, so you can always update on demand while you are working. The shared-capacity limit does apply to refreshes triggered through the REST API, not just the ones on the schedule. And with the XMLA endpoint enabled for read-write on Premium, programmatic refreshes are effectively unlimited, subject to the capacity's own resources.

So "eight a day" is really "every three hours, at times you choose", which is usually the honest answer to an hourly request on a Pro licence.

When you need a gateway, and when you do not

Before the rule: which of these needs a gateway, a SQL Server in your office or an Azure SQL database?

The office one. The rule is about reachability, not about the technology: if Power BI cannot access the source over a direct network connection, you must configure a gateway connection before you can enable a refresh schedule or run an on-demand refresh. Semantic models using cloud sources such as Azure SQL Database do not require a gateway, as long as Power BI can connect directly.

There are three kinds, and the names matter on an exam and in a procurement conversation.

Now the part that turns a working refresh into a broken one, and it is the best question on this page. A semantic model can only use a single gateway connection, so every on-premises source it touches has to be on the same gateway. And if one query merges or appends data from a gateway-connected source and a cloud source, Power BI switches to the gateway connection for the cloud source as well.

Picture that happening. Your Azure SQL table refreshed fine for a year. Somebody merges it with a spreadsheet on a network share, and now the cloud source is going through the gateway too, and it fails on credentials nobody configured. The fix is either to add a data source definition for the cloud source to the gateway, or to tick "Allow user's cloud data sources to refresh through this gateway cluster".

Worth knowing before you ask an admin for anything: gateway permissions are managed separately from workspace roles. A Contributor can schedule refresh through a gateway, but only if a gateway admin has added the data source and given them permission to use it.

Data alerts live on dashboard tiles, and only yours are yours

First: you want an email when open tickets cross 100. Where do you set it up?

On a dashboard tile, not in the report. Alerts can only be set on tiles pinned from report visuals, and only on gauges, KPIs and cards. They are not available in Power BI Desktop at all.

The rest of the behaviour, in the order it bites:

• Only you can see the alerts you set, even if you share the dashboard, and the dashboard owner cannot see the alerts you set on your view of their dashboard. An alert is a personal notification, not a team one.
• Alerts only work on refreshed data. When data refreshes, Power BI checks whether a threshold was crossed. Static data never triggers anything, and neither does an unchanged value.
• You choose how often you can be told, at most once an hour or once every 24 hours, and the notification goes to your Notification center with an optional email.
• Numeric only, and not on card tiles showing a date or time measure.
• 250 alerts across all your models is the cap.

Compare that with a subscription, which sends a snapshot of a report or dashboard on a schedule whether or not anything changed. Alerts are conditional and personal; subscriptions are scheduled and can be sent to other people. If a manager wants "tell me when", that is an alert they set for themselves. If they want "send me it every Monday", that is a subscription, and you can set it up for them.

For alerting rules that belong to a team rather than a person, Microsoft points at Fabric Activator alerts on reports rather than dashboard alerts, which is where that need has moved.

Edge cases worth knowing

A rename at the source fails the refresh in the service. If a column or table is renamed or removed upstream, refresh fails, because the service does not do a schema refresh. Fix it in Desktop and republish.

A refresh can succeed and still be wrong. Power BI logs a warning when a refresh completes but hits a non-fatal problem, such as a measure referencing a column that no longer exists. The data updates, the affected calculations return errors or blanks, and the status is not a failure. Check the refresh history, not just your inbox.

OneDrive refresh is a separate thing. Reports built on a file in OneDrive or SharePoint Online sync about every hour, and that sync tracks the file's item ID. Copying a new file over the old one creates a different ID and silently breaks the link; upload and replace instead.

Refresh times use the time zone on the settings page. The eight slots are stored against the local time zone you chose, which is the thing to check when a refresh is mysteriously an hour out twice a year.

Why the limits are shaped this way

A scheduled refresh is not free. It reads the whole source, rebuilds the model, and invalidates the cached query results that make reports feel instant, which Power BI then has to rebuild.

That is why the refresh count is capacity based rather than licence based: it is a queue on somebody's hardware. Shared capacity is shared, so it gets eight slots and a two hour ceiling. A capacity you paid for gets 48 and five hours because you are the one absorbing the cost.

The same logic explains why alerts only fire on refreshed data. There is no process sitting and watching your number. The check happens as part of a refresh, which means the fastest an alert can possibly be is the speed of your schedule. Promising a stakeholder a real-time alert on an eight-refresh schedule is promising something the architecture cannot do.

How to apply this to your own work

1. Check the storage mode of your model before touching any refresh setting. If it is not Import, the schedule is not your problem.
2. Count how often the source data genuinely changes. Most daily reports are refreshed more often than the data underneath them moves.
3. Space your eight slots around when people actually read the report, not evenly. One before the morning meeting is worth three overnight.
4. Before merging a cloud source with an on-premises one in a single query, check the gateway's cloud-source setting, or plan the failure into your afternoon.
5. Set your own alert on the number you get asked about most. It is the cheapest early warning you will ever build, and nobody else has to know it exists.
6. Read the refresh history once a week. Warnings are not failures and nobody emails you about them.

If you have paper nearby, draw your model's sources as boxes and put a line around the ones inside your network. Everything inside that line shares one gateway, and anything joining across the line is the query to look at first when refresh breaks.

Cheat sheet

The one habit to keep

Before promising anybody a refresh frequency, say out loud which capacity the workspace is on. Eight and 48 are different products, and the gap between them is where most disappointed stakeholders live.

What is the refresh schedule on your most-read report, and when did you last check that all eight slots actually ran?