Microsoft Fabric capacity throttling: why reports are slow and jobs are rejected

#How Fabric throttling works

Fabric measures usage in capacity units (CU). Operations are smoothed: interactive operations over a short window, background operations (refreshes, pipelines, Spark) over 24 hours. When smoothed usage exceeds the capacity, you go into overage, and throttling starts in stages:

Users see "slow reports" first, then errors, and finally failed scheduled jobs.

#1. Find the cause in the Capacity Metrics app

Install the Microsoft Fabric Capacity Metrics app, then:

1. Compute page → Utilization chart: see when usage exceeds 100%, and the Throttling tab for delay and rejection percentages.
2. Drill into a time point to see the top items and operations by CU.
3. Sort items by CU over 14 days. Usually a handful of items dominate: a dataset with an inefficient refresh, a Spark notebook left running, or a dataflow scheduled every 15 minutes.

#2. Common culprits and fixes

#3. Immediate relief

• Scale up the F SKU temporarily in the Azure portal (Fabric capacity resource → Change size). Changing the size gives more headroom right away.
• Pause and resume clears accumulated overage, but the carried-forward usage is billed when you pause. Use it deliberately, not as a habit.
• Turn on surge protection (where available) to limit background jobs before they push the capacity into rejection.

#4. Prevent it next time

• Alert when utilization stays above 80% (metrics app, or the capacity's Azure monitoring).
• Set a capacity owner, and review the top-10 items monthly.
• Use workspace-to-capacity assignment to isolate critical reports from experimental workloads.

Note

Throttling decisions are based on smoothed usage, so a capacity can be throttled at 9 AM because of jobs that ran overnight. Always look at the 24-hour background usage, not just what's running now.