Refresh limits and scheduling

What it does

Scheduled refresh reloads an Import model's data on a timetable you set in the semantic model settings. How many slots you get, how long each refresh is allowed to run and whether you can go outside the UI at all depend on what capacity the workspace sits on.

Key facts

Eight scheduled refreshes a day on shared capacity. Up to 48 a day on Premium capacity, PPU or Fabric capacity.
Scheduled refresh times out after two hours on shared capacity, five hours in Premium workspaces.
The scheduled times are stored against the time zone chosen on the settings page, so they don't drift with the user's browser but they do interact with clock changes.
A slot is a target, not a guarantee. Microsoft aims to start within 15 minutes of the slot, refresh can begin up to five minutes early, and a delay of up to an hour can happen if the service can't allocate resources sooner.
There's no monthly refresh interval in the UI. Monthly and dependency-driven patterns need Power Automate, Fabric Data Factory pipelines, or the refresh templates in Fabric Data Pipelines.
Power BI deactivates the refresh schedule after four consecutive failures, or immediately on an unrecoverable error such as expired credentials. The threshold can't be changed and re-enabling is manual.
Refresh over the XMLA endpoint isn't subject to the 48-a-day cap or the scheduled refresh time limit. Driven programmatically with TMSL, TOM or PowerShell, refresh frequency is bounded by capacity resources and concurrency rather than by a counter.
The XMLA endpoint has to be set to read-write on the capacity before any of that works, and that's a capacity admin setting.
The enhanced refresh REST API gives asynchronous, granular refresh — specific tables and partitions, control over parallelism and commit behaviour — without a full model reload.
Refresh needs memory on top of the model's resting size. Peak memory during refresh is higher than the model footprint suggests.
A capacity can throttle refresh when too many models process at once. Microsoft's stated mitigation is to move refresh to non-peak times.
Refresh pauses automatically on models attached to dashboards and reports nobody has visited for more than two months, unless there's a subscription keeping them alive.
A gateway is needed whenever the source isn't reachable directly over the internet, and gateway permissions are managed separately from workspace roles.

When to use / skip

Every Import model needs a schedule, so the real decisions are cadence and window. Start by asking what decision the data supports and how often that decision is made — the answer is very rarely hourly. Move to XMLA-driven refresh when the 48-slot cap genuinely bites, when you need partition-level control, or when refresh should be triggered by the upstream load finishing rather than by a clock. That last one is the strongest argument: a schedule that fires at 6am regardless of whether the warehouse loaded is a support ticket waiting to happen.

Configuration decisions

Cadence, and whether the source system can take that load in that window.
Whether refreshes are staggered across models or all fired at the same time. Fabric smooths background operations over 24 hours, so the case for manual staggering is weaker than it used to be — but the source system may still care.
Whether refresh is clock-driven from the service or event-driven from the ETL pipeline via XMLA or the REST API.
Whether the model has an incremental refresh policy, which changes both the duration and the memory profile.
Which account owns the data source credentials, and whether that account survives the person leaving.
Whether the XMLA endpoint is set to read-write, which is a prerequisite for the tooling half of this and a governance decision in its own right.

Gotchas

Once a model with an incremental refresh policy is published, you can't download the .pbix back. Keep the source file somewhere sensible and version-controlled.
Refresh memory is roughly double the resting model footprint while it runs. Sizing capacity on model size alone bites during the overnight window.
The two-hour shared capacity timeout arrives without warning as the model grows. A refresh that took 90 minutes last quarter fails silently this quarter.
48 slots sounds like plenty until someone asks for every-15-minutes. It isn't 48 evenly spaced slots you can place anywhere you like — it's 48 entries, and the practical minimum interval follows from that.
Refresh over XMLA doesn't show up in the scheduled refresh history in the same way, so monitoring built around the settings page misses it.
Clock change days shift the effective time of every scheduled refresh relative to the source system's own jobs.

Consultant notes

Give the client a refresh failure runbook at handover. Models fail at 4am and somebody needs to know whether to rerun, escalate or wait. This is the deliverable clients remember you for.
Push back on "we need it hourly" early. Most of the time the business means "not yesterday's data", which a mid-morning refresh solves for a fraction of the cost.
Use a service principal or a dedicated service account for data source credentials. Personal credentials on a production refresh is the most common single point of failure in a handover.
Event-driven refresh via XMLA is worth proposing wherever there's a real ETL pipeline upstream. It removes an entire class of "the report shows yesterday's numbers" incidents.

Worth checking again if the refresh caps or timeouts move, or once event-driven refresh becomes more native in the service.