This is the 2nd part of our Fabric Capacity Management series.
If you missed it, check the previous post:
👉 Causes and Consequences of Capacity Overloads
In the previous article, we explained what capacity throttling is and listed the most common causes. Now, let’s imagine a situation where an overload occurs, throttling kicks in, and users start escalating issues — their reports are slow or not working at all. What can the people responsible for Microsoft Fabric Capacity do?
Do nothing — sometimes
This depends on how severe the capacity throttling is — in other words, how large the CU debt is. In some cases, it may be paid off within a few minutes (or a dozen), and users can tolerate slower reports for a short time.
But if throttling is expected to last for hours, or we’re already in the interactive/background rejection phase and that’s unacceptable — then further action is required.
Notify the responsible users
Let’s say the overload was caused by a user developing a new dataset and repeatedly hitting the refresh button. Or maybe someone is testing complex DAX measures, causing strong interaction spikes. In many cases, they may not even realize the issue they’ve triggered.
Let them know. It might be enough to resolve the problem quickly.
(We’ll dive deeper into alerts and notifications in the next post — stay tuned.)
Migrate workspaces
Imagine a team has a critical presentation and needs their reports working smoothly. If possible, you can temporarily reassign their most important workspaces to another Fabric Capacity that has available resources.
This could be another production capacity, or even a “rescue capacity” — a paused capacity that’s only activated in emergency cases.
You could also offload some of the largest workspaces from the overloaded capacity, freeing up more room to repay the CU debt faster.
⚠️ Keep in mind: Migration between capacities isn’t always straightforward.
- If capacities are in the same region, there’s usually no issue.
- Cross-region migration can be problematic, especially for Dataflows, Datamarts, and other Fabric-native items.
Scale up
If you need to drastically speed up CU-debt repayment, you can scale up the capacity. This doubles your available resources — and also your cost, for the time it’s scaled. It doesn’t solve the issue immediately, but it helps the capacity return to normal more quickly.
Capacity reset
Probably the fastest — and most expensive — solution.
When you pause a capacity, it “monetizes” all the smoothed CU that was set to be consumed later. In the Fabric Capacity Metrics app, this appears as a huge CU spike at the moment of pause.
After restarting, you get a fresh start — clean capacity at 0 CU consumption. But it comes at a price.
How about your organization?
What actions do you take when your Microsoft Fabric Capacity gets throttled?
In the next post we will focus on users alerting.
#MicrosoftFabric #Fabric #MicrosoftFabricOptimization #SelfService #CitizenDeveloper #CapacityOverload #Throttling #FabricMonitoring #FabricAdmin#CapacityManagement
Leave a Reply