Microsoft Fabric's flexible billing is a gift if you pull the levers and a leak if you do not. A practical checklist to cut idle capacity cost this afternoon.

Stop paying for Microsoft Fabric capacity you do not use

Fabric has the most flexible billing of any platform we work with, and that flexibility is double-edged. Used with intent, it is cheap for what you get. Set up once and forgotten, which is how most teams leave it, it leaks money quietly all year. The usual culprit is the safest-feeling decision in the room: provision something generous and leave it running around the clock.

We cover the practical side of this in our Microsoft Fabric delivery, and You Probably Do Not Need Microsoft Fabric Yet looks at a closely related question.

The better news is that almost all of the waste is fixable in an afternoon, and you do not need a consultancy to do it. Here are the levers, in plain terms.

The savings most teams never switch on

Fabric capacity bought through Azure, the F-SKU kind, can be paused. That sounds minor and it is not. A development or test capacity that only needs office hours can sleep through evenings and weekends, and you stop paying while it does. For non-production work that takes well over half the cost out, for the price of a scheduled script.

The sizing is more granular than people assume, from a very small F2 upward, and the small tiers cost pennies an hour rather than the fortune people imagine. Because Fabric smooths and bursts short workloads, a smaller capacity often handles spiky demand perfectly well, so the instinct to size up "to be safe" usually just buys idle compute.

If a production workload is stable and predictable, a one or three year reservation knocks a meaningful slice off, in the region of a fifth to a third. One catch that surprises people: once you reserve, pausing saves nothing, because you have committed either way. So reserve the steady production base and keep the spiky and experimental work on pay-as-you-go, where pausing still earns its keep.

The afternoon checklist

Pause every non-production capacity outside working hours. Biggest, easiest win, and most teams have simply never set it up.

Right-size from the metrics, not from nerves. Look at what a capacity actually consumes before deciding it needs to be bigger.

Spread your refreshes across the day instead of firing every dataset at six in the morning. A wall of simultaneous refreshes creates the spike you then feel obliged to size up for. Stagger them and the spike disappears.

Check the viewer threshold and do the arithmetic. Below a certain tier every report viewer needs their own paid licence; above it, viewers are included. Depending on how many people read your reports, one side of that line can be dramatically cheaper, and plenty of organisations sit on the wrong side of it purely out of habit.

Question Direct Lake where plain import would do. Direct Lake is excellent, but it consumes Fabric capacity that a straightforward import model in an ordinary Pro workspace would not. Not every model earns the fancier mode.

None of this is exotic, which is precisely why it gets left undone. The biggest engine always feels like the safe choice, right up to the moment the invoice lands.

Often the right-sizing happens before anyone buys anything. We have kept clients on Azure where moving to Fabric was not yet worth the change, and steered others onto a small Fabric capacity with a plan to grow into it rather than a large one bought on day one. The honest answer is sometimes less than the platform you were about to commit to, and a partner worth having will tell you so.

We bake that thinking into every Microsoft Fabric and data platform build, but you can claim a good chunk of the saving yourself today. Open your Azure cost view, find your capacities, and ask each one a single question: is this earning what it costs, or is it just running because nobody turned it down.

If any of this sounds familiar, talk to us about your data.

Related reading

• You Do Not Need Real-Time Data. You Need Right-Time.
• Per-User Or Capacity? The One Threshold That Decides
• Getting your Business Central data into Power BI: the options