In Short: How Do You Administer a Fabric Capacity?
Watch consumption, find the item responsible, optimise before scaling. The Capacity Metrics app shows CU usage by item and operation - it is the tool that turns "Fabric is slow" into "this dataflow accounts for a third of consumption". Alert on sustained utilisation and throttling rather than brief spikes, because absorbing spikes is what smoothing is for.
Sizing Versus Administering
Choosing an F SKU is a buying decision made once. Administering it is continuous, and it is where most of the money is actually won or lost - a well-run F16 outperforms a badly-run F32 for less.
If you have not yet chosen a SKU, start with capacity sizing. This picks up afterwards.
The Capacity Metrics App
Install it, and give it fifteen minutes a fortnight. The compute page is where the useful detail lives.
Three things to read:
The utilisation timeline. Consumption against your capacity over time. You are looking for shape, not peaks - a line that sits near the ceiling for hours is a different problem from one that touches it briefly at 6am.
Consumption by item. Which dataset, pipeline, notebook or report is responsible. This is the view that ends arguments, because it names the artefact rather than the platform.
Interactive versus background. Background operations - scheduled refreshes, pipelines - are smoothed over a long window. Interactive operations - report queries - over a short one. A capacity comfortable overnight and throttled at 9am has an interactive problem, and the fix is different.
Understanding Throttling
Fabric does not fail the instant you exceed capacity. It smooths consumption over time, absorbing bursts. Sustained overuse leads to delay, and eventually rejection.
Two consequences worth internalising:
Overuse costs performance, not money. Unlike consumption-priced platforms, you cannot receive a surprise bill. The financial risk in Fabric is over-buying.
Throttling arrives late. Because smoothing hides the early symptoms, by the time users complain the cause has usually been building for days. This is precisely why the fortnightly look at the metrics is worth more than reacting to complaints.
Optimise Before You Scale
When consumption is high, the reflex is a bigger SKU. Check the item breakdown first, because in most estates a small number of items account for a disproportionate share.
Common offenders and their fixes:
- A dataset doing full refresh where incremental would do. See our incremental refresh guide - frequently the single largest saving available.
- Transformation happening in Power Query rather than upstream. Move it into a pipeline; it stops being paid for on every refresh.
- An oversized model with unused columns. Covered in report performance.
- Refreshes stacked at the same time. Staggering costs nothing and often removes the peak entirely.
- A notebook someone left scheduled after a project ended. More common than it sounds.
Scaling is the right answer when load is legitimate and growing. It is the expensive answer when one item is misbehaving, because you carry that cost for the whole reservation term.
What to Alert On
Keep it narrow, or alerts get ignored:
- Sustained utilisation above a threshold you set deliberately - not a brief spike.
- Any throttling event. These should be rare enough to be worth investigating individually.
- Refresh failures, routed to a monitored channel rather than an individual's inbox - see refresh failures.
Resist alerting on peaks. Fabric is designed to absorb them, and an alert that fires every morning trains people to dismiss it.
Development Capacity
Building on the production capacity works until a badly-written notebook throttles live reporting during the working day.
The standard arrangement: a reserved production capacity, plus a small pay-as-you-go capacity for development that is paused outside working hours - roughly a quarter of the always-on cost. It also gives you somewhere safe to test the thing you suspect is expensive.
This pairs with a proper environment strategy, which is the other half of the same discipline.
A Quarterly Rhythm
Enough for most estates:
Read the trend. Is consumption rising, and does it track adoption or something unexplained? Check the top consumers. Has anything new appeared near the top? Review the SKU. Adoption grows; a SKU right at launch is often wrong a year later - sometimes too small, occasionally too large. Confirm the reservation still fits before it renews.
Where Solv Systems Comes In
We run capacity reviews both as part of our Fabric engagements and standalone, for organisations already running a platform who suspect they are on the wrong tier or paying for inefficiency.
The work is mostly forensic: instrument the estate, read the metrics honestly, find what is actually consuming the capacity, fix it, then recommend a SKU. It fairly often ends with a recommendation to buy less than the client expected, which is generally the sign the exercise was worth running.
Sources and Further Reading
Frequently asked
The Microsoft Fabric Capacity Metrics app. Its compute page breaks consumption down by item and operation, so you can identify the specific dataset, pipeline or notebook responsible. It is the single most useful administrative tool on the platform and it is free.
Operations slow and then start being delayed or rejected. Because Fabric smooths usage over time, throttling follows sustained overuse rather than a single spike - which means by the time users complain, the cause is usually something that has been growing for days.
Optimise first, almost always. It is common for one inefficient item to account for a large share of consumption, and fixing it saves a SKU tier - which over a reserved year is real money. Scale when the load is genuinely legitimate and growing.
Sustained utilisation above a threshold you have chosen deliberately, any throttling event, and refresh failures. Alerting on brief spikes generates noise, because absorbing spikes is what smoothing is for.
Pay-as-you-go capacities can be paused, and a development capacity running only in working hours costs roughly a quarter of an always-on one. Reserved capacities cannot be paused, which is why the usual pattern is reserved production plus a small pausable capacity for development.
Quarterly as a baseline, and after any significant change in usage or content. Consumption grows as adoption grows, so a SKU that was right at launch is often wrong a year later - in either direction.
