Scheduled Refresh and Gateways

Analogy categoryAnalogies

Scheduled refresh keeps an Import-mode dataset's cached data current by re-running its Power Query queries against the source on a defined schedule, configured under a dataset's Settings > Scheduled refresh in the Service. Shared (Pro) capacity limits datasets to 8 scheduled refreshes per day, while Premium or Fabric capacity raises that ceiling to 48 per day and also unlocks incremental refresh policies that only reprocess recent partitions instead of the entire table.

🏏

Cricket analogy: Scheduled refresh is like a groundskeeper re-rolling and re-marking the pitch at set intervals between sessions rather than continuously — a club ground (Pro) might do this a few times a day, while an international stadium (Premium) can afford far more frequent prep crews.

On-Premises Data Gateways: Standard vs Personal

When a dataset sources from data behind a corporate firewall — an on-premises SQL Server, a local file share, or an on-prem SSAS cube — scheduled refresh requires an on-premises data gateway installed on a machine with network access to that source, which acts as an encrypted bridge relaying queries from the cloud Service down to the source and results back up. The standard gateway supports multiple users and data sources and can be clustered for high availability, while the personal gateway mode only supports Import refresh for a single user's own datasets and cannot be shared across a team.

🏏

Cricket analogy: A gateway is like a team's designated liaison officer who's the only one authorized to walk between the dressing room (on-prem source) and the match referee's office (cloud Service), relaying messages securely rather than letting the referee wander into the dressing room directly.

json

PATCH https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/refreshSchedule
Content-Type: application/json

{
  "value": {
    "days": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "times": ["06:00", "12:00", "18:00"],
    "enabled": true,
    "localTimeZoneId": "Eastern Standard Time",
    "notifyOption": "MailOnFailure"
  }
}

Incremental refresh (available on Premium/Fabric capacity, and with limited support on Pro for smaller datasets) partitions a table by date range so only recent partitions — say, the last 5 days — are reprocessed on each scheduled run, dramatically cutting refresh time for large fact tables.

Diagnosing Refresh Failures

When a scheduled refresh fails — due to expired credentials, a schema change breaking a Power Query step, or the gateway service being offline — Power BI sends a failure email to the dataset owner and logs details in the refresh history, viewable under Settings > Refresh history, which distinguishes scheduled, on-demand, and OneDrive-triggered refreshes with timestamps and error messages. Because refreshes queue rather than overlap, a long-running refresh can cause a subsequent scheduled trigger to be skipped entirely if it's still running when the next scheduled time arrives.

🏏

Cricket analogy: A failed refresh is like a scheduled team bus not showing up because the driver's license expired — the tour manager gets notified immediately and it's logged in the trip report, and if the bus problem drags on, the next scheduled pickup for that day gets skipped entirely.

A gateway is tied to the Windows service account it runs under; if that account's password expires or is reset without updating the gateway, every dataset relying on it will start failing scheduled refresh simultaneously, even though nothing changed in Power BI itself.

Scheduled refresh re-runs an Import-mode dataset's Power Query queries on a defined schedule to keep cached data current.
Pro/Shared capacity allows up to 8 scheduled refreshes per day; Premium/Fabric capacity raises this to 48.
On-premises sources need an on-premises data gateway as an encrypted bridge between the Service and the source.
The standard gateway supports multiple users, multiple sources, and clustering; the personal gateway is single-user only.
Refresh failures trigger an email to the dataset owner and are logged in Settings > Refresh history.
Refreshes queue rather than overlap, so a long-running refresh can cause the next scheduled trigger to be skipped.
Incremental refresh reprocesses only recent partitions instead of the whole table, cutting refresh time significantly.

Practice what you learned

1. What does scheduled refresh actually do?

2. How many scheduled refreshes per day does a Pro/Shared capacity dataset allow?

3. What component is required to refresh a dataset sourced from an on-premises SQL Server?

4. What's a key limitation of the personal gateway mode?

5. Why might a scheduled refresh be silently skipped?

Was this page helpful?

Row-Level Security

Related Study Notes in Programming

Browse all study notes

Programming

Apache Spark Study Notes

Programming · 30 topics

Programming

Apache Flink Study Notes

Programming · 30 topics

Programming

Hadoop Study Notes

Programming · 30 topics

Programming

Snowflake Study Notes

Programming · 30 topics

Programming

Apache Airflow Study Notes

Programming · 30 topics

Programming

dbt (Data Build Tool) Study Notes

Programming · 30 topics

Topics covered

#Programming#PowerBIStudyNotes#ScheduledRefreshAndGateways#Scheduled#Refresh#Gateways#Premises#StudyNotes#SkillVeris#ExamPrep

Scheduled Refresh and Gateways