If you’ve run a Fabric capacity for any length of time, you’ll know the feeling. It’s month-end, every refresh fires at once, the capacity tips over 100% and Fabric starts throttling. Reports crawl, vague Teams messages start arriving about “nothing working”, and the inevitable fix is to bump up the capacity!
Let’s ignore the wider capacity strategy missing in that scenario for now…
When Microsoft announced capacity overage, I saw them addressing this very pain point. Instead of throttling you, Fabric now bills you for the extra compute and lets everything keep running. No angry users, no frantic scaling at 9am on a Monday.
Call me cynical, but I think we all know this doesn’t come without a catch. True enough, overage is billed at three times the pay-as-you-go rate for your capacity. That might make you immediately shelve it as something you don’t want to explore, but don’t stop there. On new capacities, it’s switched on by default!
I’m not against this feature, despite my opening paragraphs 😇. I think it’s a good one. But I’ve seen enough Azure bills to know that “on by default” plus “bills automatically” is a combination worth understanding properly. So it’s important to understand why and when to use capacity overage.
So what does overage actually do?#
Back to capacity basics. Every Fabric (F) SKU gives you a fixed number of Capacity Units (CUs). Fabric smooths your usage over time and lets you borrow against the future. When that borrowing catches up with you, and the next 10 minutes of smoothed usage go over 100%, that’s when throttling kicks in. (If you’re not following, don’t worry. Microsoft’s own employees often struggle to explain this in detail.)
This is where overage steps in. Fabric pays off just enough of the “debt” to keep you out of throttling, and then bills you for it. It doesn’t clear future debt, so if you’re consistently overloaded, overage keeps quietly ticking away.
You can control it to some degree with a rolling 24-hour threshold in CU-hours (defaulted to 25% of your SKU, by the way! 🤯). Even that isn’t an exact barrier, as Fabric only checks it every five minutes. Once you hit it, overage stops and throttling comes back until older usage drops out of the window.
What does it cost?#
The headline is simple: 3x the pay-as-you-go CU rate on anything you use above your SKU. There’s no standing charge, so if you never hit 100% you pay nothing extra. Microsoft is framing it as your safety net (staffed by someone waiting with a card machine as you step off!).
Another caveat is that overage is priced off pay-as-you-go and isn’t eligible for reservation discounts. Reservations save you around 40% on capacity costs, and I always recommend them to customers once a stable production level is reached. So if you’ve reserved your capacity, overage costs you roughly five times what your normal CUs do. That’s a huge jump to consider!
To make it real, here’s a rough worked example. I’ve used the UK South pay-as-you-go rate of roughly £0.155 per CU-hour (September 2026 list price), so overage comes out at about £0.46. Check the Azure pricing calculator for your own region and agreement.
| Scenario | CU-hours in the SKU per day | Overage threshold (CU-hours per 24h) | Max overage per day | If you max it every day for a month |
|---|---|---|---|---|
| F2, default 25% | 48 | 12 | ~£5.60 | ~£167 |
| F64, default 25% | 1,536 | 384 | ~£178 | ~£5,340 |
| F64, threshold at one-third | 1,536 | 512 | ~£237 | ~£7,120 |
| F64 base capacity (PAYG) | 1,536 | — | ~£237 | ~£7,120 |
Look at the last two rows. An F64 maxing out a one-third threshold every day costs the same as running a second F64. Microsoft does say this too, though:
“Keep your threshold under a third of your daily CU-hours, because beyond that you’d be better off scaling up.”
Just because you can…#
The pricing on its own doesn’t bother me. It’s insurance, and insurance costs money. What I’m wary of is how overage will be used in the real world.
- It’s on by default. New capacities come with overage enabled at 25%. That means real spend can build up without anyone ever signing it off. If your finance team doesn’t know the meter exists, the first time they hear about it will be on the invoice. I mean, come on! One of the big business-value selling points of Fabric is consistent, predictable cost!
- It hides the warning signs. Throttling is painful, but it’s also a signal. It tells you the capacity is too small or something is badly built. Take away the pain and nobody complains, so nobody looks. You end up paying triple for a performance issue or a capacity sizing problem rather than fixing it.
- Runaway jobs get a blank cheque. A refresh stuck in a loop or a badly configured Spark notebook used to hit a wall. Now they’re just going to keep spending until they reach the threshold. Overage will also accept new heavy background jobs unless you set surge protection to 100%.
- Changing settings can bite. Scaling down with overage on can trigger a lot of automatic overage. Lowering the threshold or turning overage off can throw you straight into throttling. And you don’t get a refund on what’s already been charged.
- Working out who caused it is still on you. Monitoring has come a long way. The Capacity Metrics app now has a billed overages view, the Chargeback app breaks usage down by workspace, item and user, and you can set the overage limit straight from the Monitor hub. But overage is billed against the capacity, not against an item. If you want to charge it back, you’re splitting a capacity-level bill by usage share, which won’t be a simple conversation.
How would I use it?#
I’d keep it, but on purpose. This is what I’d recommend in my customers’ Fabric platforms:
- Check every capacity this week. Go to the OneLake catalog, then Govern → Capacities → Settings → Capacity overage, and see what’s switched on. Hopefully there are no big shocks.
- Decide capacity by capacity. Turn it on for the business-critical stuff, like the capacity that serves month-end reporting. Turn it off, or keep it tiny, for dev, test and sandboxes.
- Keep the threshold well under a third of your daily CU-hours, and work out what that number means in pounds per day.
- Set surge protection to 100% for background jobs, so overage doesn’t let new heavy work in.
- Set up alerts in two places: capacity notifications in Fabric, and a budget on the overage meter in Azure Cost Management.
- Give someone ownership. Review overage spend monthly, and treat any threshold increase made mid-incident as something to review afterwards.
Here’s a good check to see if it’s right for you. If a quarter goes by with no overage spend, it’s cheap insurance and it’s doing its job. If it fires most weeks, you don’t have an overage problem. You have a sizing or optimisation problem, and you’re paying three times the going rate to ignore it.
Overage is a really useful addition to Fabric. It just needs to be a decision, not a default.
