Forum Discussion
Fabric capacity overage feature
I was just browsing MS Fabric SKUs page and saw this little nugget tucked under the auto spark scaling.
Fabric capacity overage
Maintain smooth, uninterrupted operations without capacity throttling by turning on Fabric capacity overage for your mission-critical capacities to pay for any excess consumption. Admins can select specific capacities to enable Fabric capacity overage on and even set a 24-hour limit on paid overages.*
Has anyone seen where it is located or been able to enable this feature?
My company is the perfect example of needing this as 99.9% of the time we stay within the bursting limits of f4 except for that one random hour of a random day of the month that someone runs one report too many and our Fabric is throttled.
Hi Anonymous,
Fabric capacity overage is documented, but the control is not exposed in the admin experience yet. Right now, Fabric relies on burst smoothing and auto scale behavior tied to the SKU. There is no tenant or capacity level switch where an admin enables paid overage on demand.
What exists today
Fabric allows short burst usage within defined limits. Once those limits are crossed, throttling kicks in. Billing stays tied to the provisioned SKU, not transient spikes.
What the SKU page text signals
This reads like a forward-looking capability tied to capacity billing, similar in spirit to Azure consumption buffers. The wording suggests future support for paid overage windows and caps, not a feature already shipped.
Why you cannot locate it
No Fabric Admin portal setting
No Capacity settings blade
No PowerShell or REST surface
No documented preview enrollmentWhat is generally followed instead
Size one SKU tier higher for business hours only
Schedule heavy refresh and Spark workloads off peak
Split read heavy workloads across capacities
Monitor CU usage and throttling patterns aggressivelyThank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping
3 Replies
Hi Anonymous,
Fabric capacity overage is documented, but the control is not exposed in the admin experience yet. Right now, Fabric relies on burst smoothing and auto scale behavior tied to the SKU. There is no tenant or capacity level switch where an admin enables paid overage on demand.
What exists today
Fabric allows short burst usage within defined limits. Once those limits are crossed, throttling kicks in. Billing stays tied to the provisioned SKU, not transient spikes.
What the SKU page text signals
This reads like a forward-looking capability tied to capacity billing, similar in spirit to Azure consumption buffers. The wording suggests future support for paid overage windows and caps, not a feature already shipped.
Why you cannot locate it
No Fabric Admin portal setting
No Capacity settings blade
No PowerShell or REST surface
No documented preview enrollmentWhat is generally followed instead
Size one SKU tier higher for business hours only
Schedule heavy refresh and Spark workloads off peak
Split read heavy workloads across capacities
Monitor CU usage and throttling patterns aggressivelyThank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping
Hello Anonymous,
The “Fabric capacity overage” mentioned on the Microsoft Fabric pricing page (Azure Fabric pricing) is not yet available in the admin portal, PowerShell, or API. It describes a future capability to pay for excess compute beyond your SKU to avoid throttling.
Today (per Microsoft Docs):
Fabric automatically handles short spikes via bursting and smoothing. (Fabric throttling docs)
If usage exceeds capacity beyond smoothing, throttling occurs.
Admins cannot currently enable a paid overage toggle. Capacity sizing, off-peak scheduling, or Spark autoscale are the only practical ways to avoid throttling. (Fabric capacity management)
Bottom line: The feature exists in documentation as a concept, but no toggle or configuration is live today.
