Microsoft Fabric throttling: find the workspace behind it and show back shared capacity
Fabric applies throttling at the capacity level, so when a shared Microsoft Fabric capacity is overloaded, new operations from any workspace on it can be delayed or rejected. Report users ask why things are slow. Finance asks who used the capacity. Microsoft provides two apps that help with both questions: the Microsoft Fabric Capacity Metrics app and the Microsoft Fabric Chargeback app. This guide walks through both, step by step, using Microsoft’s own troubleshooting method, and then sets out the decisions the apps leave to you.
How Fabric decides to throttle
Fabric measures compute in capacity units (CU). Operations may burst above the capacity’s size, and Fabric then smooths their usage over future 30-second timepoints: interactive operations over at least five minutes and up to 64 minutes, and background operations over 24 hours.
Going over 100% does not trigger throttling straight away. Overage protection lets a capacity use up to 10 minutes of future capacity without throttling. After that, throttling escalates in stages:
| Future capacity already used | What Fabric does |
|---|---|
| Up to 10 minutes | Overage protection: no throttling |
| More than 10 minutes, up to 60 minutes | Interactive delay: new interactive jobs are delayed by 20 seconds |
| More than 60 minutes, up to 24 hours | Interactive rejection: new interactive jobs are rejected |
| More than 24 hours | Background rejection: all new requests are rejected |
Users see errors such as CapacityLimitExceeded or “Your organization’s Fabric compute capacity has exceeded its limits. Try again later”. Microsoft also notes that slow performance is often down to the design of an item, and only sometimes to throttling, so confirm throttling before you act on it.
Step 1: confirm the capacity was over 100% at the time
- Note the workspace name, the capacity name and the exact time the slowness happened.
- Open the Microsoft Fabric Capacity Metrics app. You need contributor or admin access to the capacity.
- Go to the Compute page, which covers the last 14 days, and select the capacity.
- On the Utilization tab, select the date on the multimetric ribbon chart, then zoom the CU % over time chart to the time of the problem. Data points are typically 30 seconds apart.
- Microsoft’s guide is explicit: if CU % stayed at or below 100% during that time, capacity throttling is not the cause of the slowness. Look at the report or query instead.
Step 2: confirm throttling happened at that moment
Utilisation above 100% does not automatically mean throttling. Switch to the Throttling tab and check the Interactive delay, Interactive rejection and Background rejection charts. Values above their 100% line mean throttling occurred. Check that the timing matches the user’s report: a capacity can throttle at one time and be fine when the user had trouble. The System events table on the same page keeps the history of throttling events.
Step 3: find the workspace and the item
- At the bottom of the Compute page, sort the Items (1 day) matrix by CU (s). The top rows are the workspaces and items consuming the most capacity, and hovering shows which operation drives each one.
- For the exact moment, select the spike in the CU % chart and use Explore to drill through to the Timepoint detail page for that 30-second interval.
- Sort the Interactive operations for timerange and Background operations for timerange tables by Timepoint CU (s), and read the % Of Base Capacity column. An operation at 150% is using one and a half times the capacity’s base resources on its own.
- Record the workspace name, item type and item name of the top contributors, and whether the load is interactive or background. Microsoft’s guide treats the top contributors as the likely causes.
Operations that Fabric rejected appear in the drill-through with limited detail (product, user, operation ID and time).
Stop it now, and limit it next time
On F SKUs, Microsoft lists three ways to stop throttling faster: temporarily scale up the SKU so carryforward burns down faster; pause and resume the capacity, which creates a billing event for the accumulated future usage and can make content unavailable; or enable capacity overage billing, which costs three times the normal capacity rate. On P SKUs, the route is Autoscale.
To limit the next event:
- Fix the item with its owner. Give the workspace and item you found to the person who can tune the model, report or schedule.
- Capacity-level surge protection rejects new background operations once the 24-hour background percentage reaches a threshold you set, and allows new background operations again below a recovery threshold. It is available for Fabric SKUs only and does not guarantee interactive work is never delayed.
- Workspace-level surge protection (preview) caps the CU a single workspace can consume over a rolling 24 hours, and each workspace has one of three states: Available, Mission critical or Blocked. Fabric checks usage every five minutes, so treat the limits as soft.
- Right-size. Consistently high throttling points to load balancing across capacities or a larger SKU.
Show back shared capacity by workspace
Once you have identified the likely contributors to the spike, the next question is who uses the capacity day to day. The Microsoft Fabric Chargeback app is a reporting app for exactly that: it shows which teams, users and workloads drive capacity usage, and breaks it down by workspace, item and domain, with drill-through pages for each and a data export.
- A capacity admin installs it from AppSource and chooses 14 or 30 days of history.
- It refreshes daily, so it is not real-time.
- Operations run by a service principal show as “Power BI Service”. If the tenant hides user data in the metrics apps, users appear as “Masked user”.
- Usage in workspaces or items with no domain is grouped under “No domain”.
- It is not supported in government clouds or in environments that use private links.
The app shows what percentage of the capacity each workspace, item or domain uses, and utilisation in CU. Microsoft describes it as a basis for allocating costs on actual consumption; which cost figure you allocate, and how, is your decision.
What the apps leave to you
Both apps report consumption. The decisions that make showback stick sit with your organisation:
- who owns each workspace when workspace names, domains and teams do not line up;
- how to treat usage under “No domain”, service principals and masked users;
- which cost figure is shared out, and whether the result reconciles to the invoice;
- what the owners of the likely contributing workspaces are asked to change, and how you will check whether those changes helped.
That is the job of the Fabric Economics Assessment: a paid, fixed-scope assessment for shared Microsoft Fabric capacity that connects the commercial bill, Microsoft-native usage evidence and your ownership context to create a defensible baseline, a draft policy and an exceptions ledger. Its initial method is transparent management showback; formal chargeback and accounting treatment stay with your Finance policies, and no guarantee of savings is made. The assessment is the current commercial entry point to FabOps.
If a throttling event, a renewal or a disputed bill has put shared capacity on the agenda, book a Fabric Economics Assessment qualification call.
Sources (Microsoft Learn, read 6 November 2026)
Related Articles
