Microsoft Fabric Capacity Metrics: Diagnosing CU Spikes at Shift Change and Month-End

Two complaints recur on a Fabric estate: reports crawl at the start of the morning shift, and everything slows during the month-end close. The natural response is to assume the capacity is too small and move from an F32 to an F64. Sometimes that is right. More often it is an expensive fix for a problem that was really about timing and a few heavy operations.

The reason to diagnose first is money. Fabric capacity is a standing monthly cost, and doubling the SKU doubles it. If the real issue is four semantic-model refreshes all scheduled for 6am colliding with the first wave of interactive users, a larger capacity masks it at twice the price while the underlying concentration remains.

The Fabric Capacity Metrics app exists precisely to answer "are we out of capacity, or are we throttled?" — and those two have different fixes. Reaching for the SKU before reading the metrics is guessing with a credit card.

Fabric does not bill or limit capacity on instantaneous usage. It smooths CU consumption over time and lets operations burst above the nominal capacity for short periods, then evens it out. This is deliberate: a brief spike from a refresh or a heavy query is absorbed rather than immediately penalised, so most short peaks never affect users at all.

Throttling happens when usage stays above capacity long enough that the smoothed total runs ahead — the platform then delays or rejects operations to bring it back in line. That delay is what users experience as slowness. The key insight is that the slowness is a symptom of sustained over-consumption, not of a single spike, so the fix is usually to reduce or spread the sustained load rather than to raise the ceiling.

Understanding smoothing changes the diagnosis. A capacity that spikes to 150% for two minutes and settles is healthy. A capacity sitting at 90–100% through the whole 6am window, then throttling, is concentrated — and concentration is a scheduling and optimisation problem before it is a sizing one.

The Microsoft Fabric Capacity Metrics app is the authoritative view. It shows CU usage over time, which items consumed it, and — critically — whether and when throttling occurred. The two things to look for are the utilisation trend across the slow window and the split between interactive and background operations.

Interactive operations are user-driven: opening a report, a query from a slicer, a DAX evaluation. Background operations are scheduled: dataset refreshes, pipelines, Spark jobs. When the morning slowdown lines up with a cluster of background refreshes finishing just as interactive load arrives, the metrics show it plainly — a background spike overlapping the interactive ramp.

The app also ranks the heaviest items, so you can see whether one oversized semantic-model refresh or one unoptimised report is responsible for most of the consumption. That ranking is what turns "the capacity is slow" into "these three operations at 6am are the cost", which is a fixable statement.

Three patterns account for most predictable spikes. The first is scheduled refreshes colliding — several semantic models all set to refresh at the top of the hour, or all timed for just before the shift so "the data is fresh for the morning", landing exactly when users arrive. The second is a heavy interactive report: an Import model that is too large, or visuals that fire expensive DAX, multiplied by concurrency when a shift logs in together.

The third is a background job — a Spark notebook, a large pipeline, a Dataflow — scheduled into the same window. Spark in particular can consume a lot of CU for a sustained period, and if it overlaps the interactive peak it pushes the smoothed total into throttling for everyone, not just the job’s users.

Month-end has its own version: everyone runs the close reports at once, finance refreshes models on demand, and reconciliation queries pile up — a genuine concurrency peak rather than a steady load. The diagnosis is the same, but the fix leans more on spreading demand and pre-aggregating the heaviest close reports.

Stagger the scheduled refreshes first — spread them across the hour and move them out of the shift-change and close windows, so background load finishes before interactive load arrives. This single change resolves a surprising share of 6am slowdowns at no cost. Move heavy Spark and pipeline jobs to genuinely quiet hours for the same reason.

Then optimise the heaviest items the metrics app named: convert an oversized Import model to Direct Lake so it stops reloading on refresh, fix the expensive DAX or visual count on the worst report, and pre-aggregate the month-end close reports so the peak reads a summarised table rather than recomputing from detail. Each reduces sustained CU, which is what throttling responds to.

Only after staggering and optimising should you compare the cost of a larger SKU against the residual peak. If the metrics still show genuine sustained saturation after the load is spread and the heavy items are fixed, then upsizing is the right call — and now it is an evidence-based one, sized to a measured peak rather than a guess. Reserved capacity can cut the cost of that step materially if the workload is steady.

Predictable slowness at shift change and month-end is a load-shape problem far more often than a capacity-size problem. Read the Capacity Metrics app to tell throttling from genuine exhaustion, separate background from interactive load, find the operations that spike, stagger and optimise them, and keep upsizing as the evidence-based last step rather than the first reflex.

The payoff is twofold: the morning and the close get faster, and you avoid paying for capacity you did not need. The question to answer before raising the SKU is simply "what did the metrics app say was consuming the capacity in that window?" — if you cannot answer it, you are not yet ready to spend.