Symptoms
- Report visuals fail or are very slow; users see capacity-related errors.
- Notebooks, pipelines and dataflows fail to start or are rejected.
- The whole workspace set on that capacity is affected at once.
1. How Fabric throttling works (short version)
Fabric smooths usage over time. When you have used more than your capacity in advance (overage), throttling steps in stages, roughly:
| Future capacity already used | Effect |
|---|---|
| Up to ~10 minutes | No throttling (overage protection) |
| ~10 to 60 minutes | Interactive delay: interactive requests delayed |
| ~60 minutes to 24 hours | Interactive rejection: interactive requests rejected |
| Over 24 hours | Background rejection: background jobs rejected too |
Check the current documentation for exact thresholds; the important point is that throttling continues until the carry-forward is "burned down", even after the heavy job stops.
2. Find the cause in the Capacity Metrics app
Open the Fabric Capacity Metrics app for the capacity:
- Utilization chart: when did CU % climb above 100%?
- Throttling tab: which stage is active now?
- Items table at the spike time: sort by CU (s) to find the item (semantic model, notebook, pipeline, warehouse query).
- Timepoint drill-through: lists the operations and users at that time.
Typical culprits: a semantic model refresh that grew large, a Spark notebook with too many executors, a dataflow without query folding, or a new report with very expensive DAX.
3. Stop the bleeding
- Cancel the running heavy operation (stop the notebook session, cancel the pipeline run, cancel the refresh in the semantic model settings).
- Pause scheduled refreshes and pipelines that are not business critical.
- Move critical workspaces to another capacity that has headroom:
Workspace settings > License info > change the capacity. Moving is quick for most items, but test that the target capacity is in the same region if your data requires it.
4. Scale up or pause/resume
For F SKUs in Azure:
az resource update --ids /subscriptions/<sub>/resourceGroups/rg-fabric/providers/Microsoft.Fabric/capacities/fabprod \
--set sku.name=F128
A bigger SKU burns down the carry-forward faster and gives more headroom.
Pause and resume clears the accumulated overage instantly, but the outstanding carry-forward is billed as a one-time charge when you pause.
az resource invoke-action --action suspend --ids <capacity-resource-id>
az resource invoke-action --action resume --ids <capacity-resource-id>
Warning
Pausing stops every workload on the capacity until it resumes, and adds the overage to the bill. Use it only with approval, when the outage cost is higher than the charge.
5. Fix the offending item
- Semantic models: incremental refresh, remove unused columns, reduce high-cardinality columns, avoid many-to-many relationships where not needed.
- Spark: right-size the environment pool, cap executors, cache less.
- Pipelines and dataflows: push work to the source (query folding), stagger schedules.
Prevent it next time
- Separate capacities for production BI, data engineering and development/ad-hoc.
- Alerts on capacity utilisation (Capacity Metrics or Azure Monitor for F SKUs) above 80%.
- Surge protection settings where available, to limit background jobs before they cause throttling.
- Review the top CU consumers weekly with workspace owners.