Fabric capacity throttling: why reports suddenly crawl, and how surge protection helps

A report that took two seconds yesterday takes twenty today, and a refresh that always worked gets rejected — classic signs the Fabric capacity behind them is throttling. The mechanics are documented and predictable once you know the three windows.

The three throttling stages

Fabric smooths usage over time, and an overloaded capacity — one past 100% of its compute — throttles in escalating stages based on how much future usage has been burnt:

A background rejection of 250% means the capacity consumed two and a half times its daily compute — and because in-progress background jobs aren't stopped, they can keep extending the pain. What feels like one long outage can be two back-to-back throttling events as smoothed usage dips under 100% and climbs again.

Find the evidence

Install the Microsoft Fabric Capacity Metrics app and open the Compute page:

• The throttling charts (interactive delay, interactive rejection, background rejection) show your consumption as a percentage of each limit over time.
• System events names each state change — InteractiveDelay, InteractiveRejected, AllRejected, SurgeProtectionActive — with timestamps you can line up against user complaints.
• The Timepoint page shows which operations were rejected (Rejected, RejectedSurgeProtection).

Set up surge protection

Surge protection sacrifices background work early to keep interactive users alive. Two thresholds, set per capacity in the admin portal (Capacity settings > the capacity > Surge protection):

• Rejection threshold — when the 24-hour background percentage reaches it, new background operations are rejected. Without surge protection, that rejection only starts at 100%.
• Recovery threshold — where the background percentage must fall before background operations are accepted again.

Microsoft's own tuning advice: read your Background rejection chart first. If background usage averages 50% with peaks at 75% that coincide with interactive rejections, start with a rejection threshold between 60 and 75 and a recovery threshold between 40 and 60 — then adjust from observed behaviour. Since October 2026, semantic models also report compute usage continuously during long background operations instead of mostly at completion, so these thresholds act on current reality rather than after-the-fact spikes.

A workspace-level variant (preview) caps how much compute one workspace can consume and can block a runaway workspace automatically — with a Mission critical setting to exempt the workspaces that must never be blocked.

Pause animation

1. 1Read the Background rejection chart
2. 2Set rejection above typical, below peak
3. 3Set recovery near typical
4. 4Watch system events
5. 5Adjust

Protect what's critical

The documented limits keep expectations honest:

• Surge protection applies to Fabric SKUs only, doesn't stop in-progress jobs, and some UI-initiated requests bill as background — so they get rejected too while it's active.
• It doesn't guarantee interactive requests are never delayed: a capacity at its compute ceiling still throttles.
• Microsoft's blunt line: to fully protect critical solutions, isolate them in a designated capacity.

Turn on throttling notifications (banner and email, in capacity settings) so admins hear about a throttled state from the platform, not from users.

Sources

• Manage surge protection for Fabric capacities — Microsoft Learn
• Metrics app calculations — Microsoft Learn
• Compute page in the Fabric Capacity Metrics app — Microsoft Learn
• Power BI October 2026 Feature Summary — Microsoft Fabric Community blog