Fabric capacity overage is on by default now, and it bills the spike at three times list

Microsoft Fabric has always had one honest failure mode: run past your capacity and the service throttles you. Interactive queries slow, then background jobs get rejected, and the fix was a bigger SKU. At the end of September that changed. Capacity overage, the feature that pays the excess instead of throttling it, went generally available with the Barcelona conference announcements, and the documentation states the terms without ornament.

Three terms matter. Overage "charges at three times the pay-as-you-go rate," per the overview page, through a separate meter, and it is not a reservation discount line. "Capacity overage is enabled by default when you create a Fabric capacity," with a default rolling threshold of 25 percent of the SKU's daily capacity units. And the threshold "is a spending threshold, not a hard spending cap": Fabric evaluates it every five minutes, in-flight operations finish, and the page says plainly that "your actual overage charges can exceed the threshold you set."

The meter itself is not new. The Azure retail price list for East US carries "Capacity Overage Capacity Usage CU" at $0.54 an hour against $0.18 for a standard capacity unit, effective 1 October 2025. The preview ran a year. What changed in September is the default.

Where the arithmetic lands

Take an F64 in East US. Sixty-four units at $0.18 is $11.52 an hour, $276.48 a day, and the SKU delivers 1,536 CU hours in that day. The next size up, an F128, costs exactly that much again. Overage on the F64 at the default 25 percent threshold allows 384 extra CU hours a day, which at $0.54 comes to $207.36. Push the threshold to a third, 512 CU hours, and the overage bill reaches $276.48: the price of the F128 you did not buy. Microsoft's own guidance says to keep the threshold "below one-third of your daily CU hours," and the chart shows why. Below the line, the meter is cheaper than the upgrade. Above it, you are paying for a bigger SKU and not getting one, because overage "doesn't increase SKU size or available resources; it only prevents throttling."

So the 25 percent default is set just under the break-even, which is fair, and the product is well designed for what it claims: absorbing a rare spike without an on-call admin resizing capacity at two in the morning. The question for a head of data is not whether the feature is good. It is whether anyone in the organization knows it is on.

The default is the review

A capacity created last week has overage enabled unless the person clicking through the portal toggled it off. The spending threshold is quota-backed, not a cap. And the behavior that triggers it, smoothed usage crossing 100 percent, is precisely the behavior a team under-sizing its capacity to save money will produce on a regular basis, at which point the saving is being recovered at three times list. The documentation says as much: "If you're throttled regularly outside of these scenarios, scale up instead."

Fabric was sold as the capacity model that made BI cost predictable, the counterweight to per-seat pricing. A metered overage on by default, with a threshold that charges can exceed, moves it one step toward the consumption models it was meant to replace, and the F0 on-demand SKU announced in the same week, still in preview with no published multiplier, is the next step on that path.

Verdict

Worth enabling, deliberately, on capacities where a throttled morning costs more than $0.54 a unit. Audit every capacity in the tenant this week, because the decision was made for you on any created since the end of September. And set the threshold yourself: at a third of daily units the meter costs the same as the SKU above, and above that it is an upgrade you are renting by the hour without receiving.