Fabric capacity overage is GA: throttling can now become a bill

Microsoft Fabric capacity overage is now generally available, and it is switched on by default when you create a new Fabric capacity. In practice that means a capacity that would have been throttled can instead keep running and send the excess to your Azure bill.

That can be a good trade or an expensive surprise. It depends on whether you understand the mechanics, so here is what the documentation says and what I would check this week.

What capacity overage does

Capacity overage is an opt-in feature (on by default for new capacities) that pays for eligible excess capacity usage, up to a rolling 24-hour threshold that a capacity admin sets. It is available only for F SKUs.

Normally, when smoothed usage exceeds what your SKU can absorb, Fabric starts throttling: delays first, then rejections. With overage on, Fabric intervenes at the point where throttling would begin. It reconciles the excess by charging your Azure subscription, and jobs keep running without user-visible delays.

Two things it does not do:

• It does not add compute or memory. Microsoft says plainly that it prevents throttling but does not make anything faster. Semantic model memory limits and concurrency limits still apply.
• It does not override surge protection. If you want Fabric to keep rejecting new background jobs under pressure, set the surge protection limit to 100%.

How it is priced and capped

The pricing model is simple to state:

• A separate Azure meter bills overage at three times the pay-as-you-go rate.
• It only applies to CU hours beyond your SKU that would otherwise have triggered throttling.
• There is no standing charge. If you never overload, you pay nothing extra.

The cap works like this. The admin sets a threshold in CU hours. Fabric compares it against processed overage over the past 24 hours and evaluates it every 5 minutes. When the threshold is reached, overage stops and throttling resumes until older usage rolls out of the window.

The threshold also needs quota. The required quota is one 24th of the threshold, so a 48 CU hour threshold adds 2 CUs to your quota. If you do not have the headroom, you cannot enable it.

For new capacities, the default threshold is 25%. The slider moves in 5% steps of the base SKU, or you can enter an absolute value in CU hours.

The details worth reading twice

The documentation is careful about a few points that are easy to skim past:

• The threshold is a spending threshold, not a hard cap. Fabric evaluates periodically and operations already running continue, so charges can exceed the number you set.
• Overage pays off the debt for the current window. It does not clear future debt. Under sustained overload it can stay active for a long time and run all the way to your threshold.
• If you switch it on during a heavy throttling event, Fabric charges all the accumulated carry forward at that moment.
• Scaling a capacity down with overage enabled can produce large automatic charges.
• It admits new work. Because throttling is prevented, large new background jobs can also get in. That is the surge protection point above.

A quick sizing example

Microsoft suggests keeping the threshold below one third of your daily CU hours. Because overage costs three times the normal rate, that is roughly where paying for overage costs the same as scaling up.

An F64 has 1,536 CU hours per day, so one third is 512. The default 25% threshold on an F64 works out to 384 CU hours. At three times the rate, a full 384 CU hours of overage costs about the same as 1,152 CU hours at the normal rate, which is roughly three quarters of a day of that capacity. That is the planned worst case before overshoot, and it is the number to compare with your budget.

What this means for you

Overage is a safety net, not a capacity plan. Microsoft says the same: use it when uptime matters and you occasionally hit limits, such as a month-end refresh window or a rare spike. If you are throttled regularly, scale up instead.

A short checklist:

1. Open the capacity settings for each F SKU capacity and check whether overage is on. Do not assume the answer: it is on by default for newly created capacities, so older ones may differ.
2. Look at the threshold and convert it to CU hours and then to money at three times your rate. Decide whether that number is acceptable to the person who pays the Azure bill.
3. Check your quota. If the threshold needs more than you have, you will find out when you try to enable it, not before.
4. Set up tracking. The Capacity Metrics app shows processed overage and capacity state, and Azure Cost Management shows billed overage on its own meter.
5. Turn on overage notifications. Email notifications for entering and leaving overage are in preview, and they tell you when the safety net is in use.
6. Decide who looks at it. When overage activates, someone should review the workloads and decide whether to optimise or scale.

Takeaway

After two decades in data, I have seen many "automatic" features turn into recurring cost lines because nobody owned them. Capacity overage is useful, but only if a person owns the threshold and reads the signal. Treat every overage event as a prompt to look at workload, not as proof that everything is fine.

Do you know today whether overage is on for your Fabric capacities, and what it would cost at the threshold?

Sources

• Capacity overage in Microsoft Fabric (Microsoft Learn)
• Enable capacity overage in Microsoft Fabric (Microsoft Learn)
• What's new in Microsoft Fabric, September 2026 (Microsoft Learn)