How Fabric charges capacity (simplified)
- A capacity provides a number of CUs per second.
- Interactive operations (report queries) are smoothed over a short window (minutes); background operations (refreshes, Spark jobs, pipelines) are smoothed over 24 hours.
- Bursting lets work use more than the SKU for a while; the "debt" is paid back from future capacity.
- When future capacity is used up beyond thresholds, throttling delays then rejects work (see the throttling post).
So a 30-minute refresh peak doesn't need a SKU sized for that peak. Sustained background use is what matters.
1. Read the Capacity Metrics app
| View | Look for |
|---|---|
| CU % over time (smoothed) | Sustained level, not spikes |
| Throttling charts (interactive delay/rejection, background rejection) | Any time above 100% |
| Items by CU | Which semantic models, notebooks, pipelines, warehouses consume most |
| Operations | Refresh vs query vs Spark vs copy |
2. Optimise the top consumers
| Consumer | Typical fix |
|---|---|
| Semantic model refreshes | Incremental refresh, folding, fewer refreshes (see the refresh post) |
| Report queries | Model size and DAX fixes (see the semantic model post) |
| Spark notebooks/jobs | Right-size Spark pools/environments, fix inefficient code, stop idle sessions |
| Data pipelines | Fewer activity runs, efficient copies |
| Warehouse queries | Statistics, avoid huge scans, result reuse |
| Dataflows Gen2 | Move heavy transforms to pipelines/notebooks or the warehouse where cheaper |
Often 3–5 items cause most of the load.
3. Separate workloads
| Capacity | Contents |
|---|---|
| Prod BI | Production semantic models and reports |
| Prod data engineering | Pipelines, Spark, warehouse loads |
| Dev/test | Development workspaces |
Separation stops a runaway Spark job from throttling executive dashboards, and lets you size and pause each independently. Assign workspaces to capacities accordingly.
4. Surge protection
Set the capacity's surge protection (background operation rejection threshold) so background jobs are rejected before they push the capacity into interactive throttling. Interactive users are then protected at the cost of some background retries. Tune with the metrics app.
5. Pause non-production
Pay-as-you-go F capacities can be paused when not used. Billing for compute stops (storage continues). Automate:
az resource invoke-action --action suspend --ids /subscriptions/<sub>/resourceGroups/rg-fabric/providers/Microsoft.Fabric/capacities/fabdev
az resource invoke-action --action resume --ids /subscriptions/<sub>/resourceGroups/rg-fabric/providers/Microsoft.Fabric/capacities/fabdev
Pausing with outstanding "carry-forward" usage settles it at pause time, so a pause right after a big job can create a charge. Content on a paused capacity is unavailable.
6. Choose the SKU and commitment
- After optimisation, take the sustained CU % over a month (including month-end).
- Pick the SKU where typical smoothed usage sits around 60–80% with throttling never reached in normal operation.
- Reserve (commit) the steady baseline capacity; keep pay-as-you-go for capacities you pause or that may change.
- Scale up temporarily for known events (year-end) instead of sizing for them permanently.
7. Governance
- Who can assign workspaces to production capacities (capacity admins/contributors).
- Monthly review: top items by CU, throttling events, growth.
- Chargeback/showback by workspace using the metrics app data.
Tip
Before buying a bigger SKU, check the top item in the metrics app. A single semantic model refreshing every 15 minutes with a full reload can consume more than the rest of the capacity combined.
Checklist
- Smoothed usage and throttling understood in the metrics app
- Top items optimised
- Workloads separated across capacities
- Surge protection set
- Non-production paused automatically
- SKU and reservation chosen after optimisation; monthly review