Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/03-power-query-and-dataflows/feature-scheduled-refresh.md
feature-scheduled-refresh.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

Scheduled refresh is the Power BI service re-running a semantic model's queries at times you choose, using stored credentials and, where needed, a gateway. It's configured per model under Refresh > Schedule refresh in the workspace.

Key facts

  • Refresh frequency caps by licence: Power BI Pro allows up to 8 scheduled refreshes a day; PPU and Premium or Fabric capacity (F SKU, EM, P) allow up to 48. On-demand and API refreshes don't extend the schedule but do count toward resource usage.
  • Timing is best-effort. Microsoft targets starting within 15 minutes of the slot, refresh can begin up to five minutes early, and a delay of up to an hour is possible if the service can't allocate resources.
  • Power BI deactivates the refresh schedule after four consecutive failures, or immediately on an unrecoverable error such as expired credentials. The threshold isn't configurable.
  • After two months of inactivity — no user opening any report or dashboard built on the model — scheduled refresh is paused, the owner is emailed, and the schedule shows as Disabled.
  • With a standard on-premises gateway, credentials belong to the data source as configured by the gateway admin, so the model owner doesn't supply them. With personal mode, the owner does.
  • Refresh history (Refresh > Refresh history) gives status, start time, duration and error message per attempt. That's your first stop, always.
  • There's no built-in monthly refresh interval. Microsoft points at Power Automate for that, or at Fabric Data Pipelines with refresh templates if the client has Fabric.
  • For on-premises SharePoint sources, refresh supports Anonymous, Basic and Windows (NTLM/Kerberos) only — not ADFS or forms-based authentication.

When to use / skip

Every Import model needs a refresh schedule, so the question is cadence, not whether. Start from what the business decision actually needs rather than what they ask for: a daily overnight refresh covers most reporting, and each extra slot costs source load and capacity. DirectQuery and live-connection models mostly don't need it, though the service may still process metadata such as role security changes. Where someone insists on eight refreshes a day on Pro, check whether they need fresher data or just faster answers to a support question — usually the latter.

Configuration decisions

  • Cadence and time slots, set against the source system's own load profile and the client's time zone.
  • Which account owns the model and therefore the schedule, and what happens when that person leaves.
  • Whether the refresh path runs through a standard gateway (credentials centrally held) or personal mode (they aren't).
  • Whether refresh failure emails go to the owner only or to a monitored distribution group.
  • Whether refresh needs orchestrating rather than scheduling — dataflow first, then model, with dependencies — which pushes you toward Fabric pipelines.
  • Whether the model gets incremental refresh so the nightly window stays viable as history grows.

Gotchas

  • Four consecutive failures disables the schedule silently as far as most users are concerned. Nobody notices until a Monday morning meeting looks at Thursday's data.
  • The two-month inactivity pause catches seasonal and year-end reports. They stop refreshing exactly while nobody's looking, then get opened stale.
  • Refresh failure notifications default to the model owner. If that's the consultant who built it, the client hears nothing after handover.
  • Peak memory during refresh is higher than the model's resting size, so capacity that's comfortable during the day can fail overnight when several models refresh at once.
  • Scheduling eight models at 06:00 doesn't run eight refreshes at 06:00 — they queue, and the last one may start an hour later than you planned.

Consultant notes

  • Change the refresh failure contact to a group address before handover, and confirm someone actually reads it. This is the single most common post-go-live gap.
  • Stagger start times across models rather than lining them all up on the hour. It costs nothing and removes a whole class of intermittent failure.
  • Give the client a one-page runbook: how to read refresh history, how to re-enter credentials, how to re-enable a disabled schedule, and when to escalate.
  • If they're asking for near-real-time, price the alternatives honestly — DirectQuery, hybrid tables or Direct Lake — rather than stacking 48 refreshes and hoping.

Revisit if the per-licence refresh caps change, or once the client's overnight window starts running past the working day.

Was this accurate?
Related
Refresh limits and scheduling06-capacity-and-performanceImport storage mode01-semantic-modelsXMLA endpoint09-alm-and-deploymentData gateways03-power-query-and-dataflowsFabric capacity and F SKUs06-capacity-and-performanceQuery caching and semantic model scale-out06-capacity-and-performance