What it is
A slow refresh is a semantic model refresh that completes successfully but takes materially longer than its historical baseline. There is no universal threshold — a refresh that typically takes 5 minutes but now takes 25 minutes is slow, even if it eventually succeeds.
Slow refreshes are a leading indicator of problems. A refresh that gradually gets slower over weeks often ends in a timeout failure. Catching the trend early gives admins time to intervene.
Causes include growing source data volumes, degraded source query performance, capacity contention from concurrent refreshes, and inefficient Power Query transformations.
Why it matters for Power BI teams
- Slow refreshes consume capacity resources (CPU and memory) for longer, reducing headroom for other workloads.
- They increase the risk of timeout failures, especially as data volumes grow month over month.
- Scheduling conflicts arise when a slow refresh overlaps with the next scheduled refresh or with other datasets.
- Per-table timing reveals which specific table is the bottleneck, but only for PPU and Fabric workspaces.
- Report users may experience delayed data availability if refreshes finish after their expected window.
Why Power BI doesn't catch it well
Power BI records refresh duration but does not compare it to historical averages or alert when a refresh takes unusually long. There is no built-in "slow refresh" concept.
The refresh history view shows individual durations, but admins must manually review and mentally track trends. There are no charts, trendlines, or anomaly markers.
Power BI does not provide per-table timing visibility in the portal UI. Identifying which table caused the slowdown requires Enhanced Refresh API access or XMLA tracing.
How teams detect it today
- Manually reviewing refresh history and comparing durations over time.
- Setting up calendar reminders to spot-check critical dataset refresh times.
- Waiting for timeout failures — the ultimate sign that a slow refresh went unaddressed.
- Using Power BI REST API scripts to log durations and generate periodic reports.
- Investigating only when users report that data is not yet available at expected times.
How SummitView helps
- SummitView tracks every refresh duration and compares it against historical averages, flagging anomalies automatically.
- Configurable alerts trigger when a refresh exceeds a percentage threshold over its average (e.g., 200% slower).
- Per-table refresh timing (PPU and Fabric) pinpoints exactly which table is causing the slowdown.
- Duration trend charts make it easy to see gradual degradation before it becomes a failure.
- Scheduling collision detection identifies when slow refreshes overlap with other workloads.