F0 and capacity overage: two changes to the Fabric bill

Two announcements from FabCon Europe change how a small Fabric setup gets billed. One of them, the F0, we have wanted since Fabric launched. The other, capacity overage, is a safety net that is now switched on for every new capacity, and it is priced like one. This post covers what each does, what we know about timing, and what we would do about them.

If you are new to how Fabric bills, How much is Fabric? explains capacity units and what common workloads cost, and Eight ways to keep your Fabric bill down covers the choices that keep the bill reasonable. This post is the update to both.

F0: a capacity that costs nothing while it sits there

Until now the smallest Fabric capacity you could buy was an F2, and it bills by the hour whether or not anything is running. If you wanted to try Fabric without that standing charge, you took the 60-day trial, built what you could, and then faced the real decision when the trial ended. The trial was useful because it was free. It was awkward because it was temporary.

A paid F2 is not expensive, but it is always on. The usual way to keep the cost down was to pause the capacity when nobody needed it, and because people forget, that meant a Logic App or an Automation runbook to pause and resume it on a schedule. We have built that for clients. It works, and it is one more thing to own.

The F0 removes the standing charge. Microsoft describes it as a way to “get started with Fabric and OneLake without an upfront capacity commitment”: a zero-provisioned capacity that stays on all the time and bills only for the compute you consume, with storage billed separately as it is today. Nothing running, nothing charged. No pause schedule, no trial clock.

It builds on the on-demand billing model that Fabric already uses for Spark, which went GA this year under its new name after launching as Autoscale Billing for Spark. In that model the capacity admin sets a maximum number of capacity units, jobs are metered as they run with no 24-hour smoothing, and when the limit is reached interactive work is throttled and background work queues. The FabCon announcement extends that model to the other Fabric workloads, so on an F2 or larger you will be able to move individual billing categories to on-demand while keeping the rest on provisioned capacity, and an F0 runs every supported category that way by default.

What we do not know yet matters. On-demand compute is priced as a multiplier of the pay-as-you-go rate, and Microsoft has not published the multiplier for F0 or for the workloads beyond Spark. The one number that has appeared so far is in the documentation for Planning in Fabric, which says planning sessions on an F0 bill at 1.5 times their base CU-hours. Expect something in that range: you pay more per unit for the freedom to pay for nothing when idle. For a capacity that runs a few loads a day and some report refreshes, that trade is a good one. For a capacity that is busy all day, a reserved F SKU will still win.

When you can try it

Microsoft said at FabCon on 29 September that F0 and the wider on-demand billing are “coming soon”, with a preview expected in the following weeks, and that timelines are subject to change. As of early November there is no F0 on the Azure pricing page and no F0 documentation on Microsoft Learn beyond the planning note above. We will update this post when the preview opens. In the meantime, the Fabric trial still gives you 60 days, now as an F4 or an F64 depending on your tenant, so there is no reason to wait to start building.

Our plan is to put the F0 through the same tests we ran for the FabCon session: load 100 million rows a few different ways, refresh a Direct Lake and an Import model, and see what the bill says. If you want to know what we find, the contact page is the place to say so.

Capacity overage: now on by default, and priced to be avoided

Capacity overage is the other half of the story. When a Fabric capacity runs past its size, it slows down, then starts rejecting new work. Capacity overage changes that: instead of throttling, Fabric bills your Azure subscription for the excess at three times the pay-as-you-go rate, up to a rolling 24-hour threshold you set, and your jobs keep running. It went into preview in April and is now generally available.

Two things about it deserve a closer look.

It is on by default. When you create a Fabric capacity today, overage is enabled with a threshold of 25% of the capacity’s daily CU hours. You can change or turn it off during creation, or afterwards in the OneLake catalog under Govern and Capacities, or in the admin portal under Capacity settings. If you created a capacity recently and did not look at that setting, go and look.

The threshold is not a cap. Microsoft’s documentation calls it “a spending threshold, not a hard spending cap.” Fabric evaluates overage every five minutes, in-flight operations are allowed to finish, and anything that accrued before the capacity entered overage is billed too. Your charges can run past the number you set.

Here is what the default means on an F2. An F2 gives you 48 CU hours a day. The 25% threshold allows another 12 CU hours a day at three times the rate, which is the price of 36 CU hours of normal pay-as-you-go. A capacity that hits its threshold every day is paying for an F2 and three quarters while getting the compute of an F2 and a quarter. An F4 would cost twice an F2 and give you 96 CU hours. Microsoft’s own guidance says the same thing in different words: keep the threshold below a third of your daily CU hours, because above that it costs about the same as moving up a SKU.

There are two more behaviours to know before you leave it on. If you switch overage on while the capacity is already throttled, Fabric bills the whole accumulated backlog at the overage rate at that moment. And if you scale a capacity down while overage is enabled, the usage that no longer fits can turn straight into overage charges. Check the load before you do either.

We are not saying never use it. Overage is the right tool when uptime matters more than the bill and the spikes are rare: a month-end close that needs the reports to stay up, or a one-off load you cannot schedule. For a small capacity that runs predictable loads, we would rather spend the money on an F4 and set overage to a low threshold, or turn it off, and let the tools below do the protecting.

Protect production without paying the premium

The reason overage exists is a real problem: on a shared capacity, one heavy job can slow or stop everything else. A development dataflow should never take down the production reports. The fix we prefer is to decide in advance what matters and set the capacity up to protect it.

Set up notifications first. Capacity notifications can email you and show a banner to users when the capacity approaches a throttled state, enters one, and recovers. Overage has its own notifications, in preview, for when overage starts, when it reaches a percentage of your threshold, and when it runs out. Ten minutes of setup, and the first time a capacity runs hot you hear about it from Fabric rather than from a user.

Then turn on capacity-level surge protection. It lets you pick a point at which the capacity stops accepting new background jobs, before deep throttling sets in and before the people opening reports feel it. Rejected jobs need a rerun, so treat it as a guard rail. It also closes a gap in overage: overage keeps the capacity accepting new work, including new large jobs, so Microsoft recommends a surge protection limit of 100% alongside it if you do not want overage admitting the very jobs that caused the problem.

The piece we have wanted is workspace-level surge protection, which is in preview. It lets you cap how much of the capacity any single workspace can use over a rolling 24 hours, as a percentage of the capacity, and it adds three states for a workspace: Available, Mission critical and Blocked. Mark the production reporting workspace as mission critical, and it is exempt from the capacity’s surge protection rules. Leave the development and test workspaces as available with a sensible cap, and a runaway ETL job in one of them gets blocked instead of starving production. You can block a workspace by hand too, for a fixed number of hours or until you release it, and notifications tell you when a workspace is approaching its limit or has been blocked.

Capacity-level throttling still applies once the whole capacity is out of CUs, so mission critical is a priority, not a guarantee. But it is the first time Fabric has let a small team say “these reports matter more than that notebook” in a setting rather than by buying a second capacity.

What we would do this week

• Open each Fabric capacity you own and check the capacity overage setting. Decide deliberately whether it stays on, and if it does, set the threshold well below a third of the daily CU hours.
• Turn on capacity notifications and overage notifications, with an email address someone reads.
• Enable capacity-level surge protection and, if your tenant has the preview, workspace-level surge protection. Mark production reporting as mission critical and cap the rest.
• If you have been running a scheduled pause to keep an F2 cheap, keep it for now and watch for the F0 preview. When it lands, run your real loads on it for a week and compare the bill.

Fabric now has more levers for the small customer than it has ever had: a capacity that costs nothing when idle, a safety net when the bill matters less than uptime, and a way to say which workspaces come first. Used in that order, they are all good news. The only one to be careful with is the one that was switched on for you.

If you would like help working out which of these fits your setup, or why a Fabric bill came in higher than expected, that is part of our Microsoft Fabric work.