The Microsoft Fabric Capacity Metrics app shows you the numbers but never explains them. Pick the page you're on and the thing that's confusing you — we'll translate it into plain language and tell you whether it's actually a problem.
By the DataTako team — Microsoft Fabric & Power BI specialists · Last reviewed July 2026
The Fabric Capacity Metrics app is a free Power BI app from Microsoft that monitors how your capacity's compute is used. It's a single report split across a few pages, all filtered by the Capacity Name selector at the top. Most confusion comes down to three ideas — bursting, smoothing and throttling — plus knowing which page answers which question.
To stay fast, Fabric lets an operation temporarily use more compute than your SKU provides — that's bursting. So bursting doesn't punish you, Fabric then smooths that cost across future 30-second timepoints: interactive work over 5–64 minutes, background work over a full 24 hours. This is why your capacity can sit at or above 100% utilisation without anyone noticing — high utilisation on its own is not throttling.
You only get throttled when smoothing runs out of runway and you've eaten too much future capacity. It happens in progressive stages, so a short spike costs you nothing and only sustained overuse rejects work:
| Future usage | Stage | What you feel |
|---|---|---|
| ≤ 10 minutes | Overage protection | Nothing — free headroom |
| 10–60 minutes | Interactive delay | New interactive requests delayed 20 s |
| 60 min – 24 h | Interactive rejection | Interactive requests rejected (users get an error) |
| > 24 hours | Background rejection | Everything rejected, incl. refreshes & pipelines |
Recovery is predictable: minimum time = ((% − 100) ÷ 100) × the window. A 250% background rejection clears in about 36 hours; a 250% interactive rejection in about 90 minutes. Capacities are self-healing, so you can wait — or recover faster by temporarily raising the SKU, or pausing and resuming the capacity.
The Compute page (last 14 days) is your overview: utilisation, throttling, overages and the per-item matrix. The Timepoint page freezes one 30-second moment and ranks every operation by CU, so you can find the exact culprit behind a spike. The Storage page (last 30 days) is a completely separate meter — OneLake storage in GB, billed apart from compute. Slow or throttled? Compute. Rising bill with no slowness? Storage.
The full text behind the tool above, so you can scan or search it directly.
Almost always fine — by design. Overage protection lets you consume 10 minutes of future capacity with no throttling, and smoothing spreads the rest across future timepoints. Utilisation exceeding 100% doesn't automatically mean throttling. What to do: check the Throttling chart, not the utilisation number — no delays or rejections means you're just using what you paid for.
Usually a real problem — act on it. Red means Fabric started delaying or rejecting work. Three stages by future usage: interactive delay (10–60 min → 20-second delay), interactive rejection (60 min–24 h → interactive requests refused), background rejection (over 24 h → everything rejected, including refreshes and pipelines). A tab above 100% means that window is over budget. What to do: drill to the Timepoint page, sort by CU, and fix, reschedule, or scale.
Predictable — you can estimate it. Minimum recovery time = ((% − 100) ÷ 100) × the window. 250% background rejection ≈ 36 hours; 250% interactive rejection ≈ 90 minutes; 250% interactive delay ≈ 15 minutes. What to do: capacities self-heal, so you can wait — or recover faster by temporarily raising the SKU or pausing and resuming the capacity.
A warning sign to monitor. Overage (Carryforward) shows Add (debt added), Burndown (debt paid) and Cumulative (running total). Overage (Billed) only appears if capacity overage billing is on — Fabric pays off the excess by charging your Azure subscription at 3× the normal rate. What to do: watch whether cumulative carryforward returns to zero; if it only grows, optimise or scale.
Info — but people read it backwards. Red columns are Interactive %, blue columns are Background % — the opposite of what many assume. Baby-blue and green are the non-billable preview variants. The grey dotted line is your CU % limit; an orange dotted line is the autoscale limit. What to do: ignore non-billable usage when hunting a problem — it doesn't drain capacity or cause throttling.
Info — your throttling history. The table logs state changes: NotOverloaded, InteractiveDelay, InteractiveRejected, AllRejected, SurgeProtectionActive, ManuallyPaused. An empty table means no state change in the last 14 days, which is good. What to do: use it as the quick "has this capacity thrown throttling events lately?" check.
Depends — a performance signal, not billing. Colour is the performance delta versus 7 days ago: no colour above −10, orange −10 to −25, red below −25. Negative means items got slower over the week. What to do: chase red items that also have high CU and users — small models can show wild deltas that don't matter.
Exactly what this page is for. It freezes one 30-second moment and ranks every operation by CU across two tables (interactive and background), showing Workspace, Item kind, Operation, User and the CU columns. What to do: sort by Total CU (s), note the top 2–3 items, and optimise, reschedule, or move each to another capacity.
Info — the columns everyone misreads. Total CU (s) is all CU the operation used (counts toward overload). Timepoint CU (s) is the slice assigned to this 30-second window. Throttling (s) is throttling applied to this op. Duration (s) is how long it ran — and it has no impact on throttling. What to do: judge cost by CU, never by duration.
Normal — not double counting. A single refresh can trigger several backend operations, including automatic retries, each recorded under its own activity/operation ID and shown as its own row. What to do: group mentally by item and time; don't panic at the row count.
Normal — that's smoothing. Because of smoothing, an operation's CU is spread across windows; a background operation that finished yesterday can still contribute CU to today's timepoint (24 hours = 2,880 intervals). What to do: expect it — "who caused this spike" can point at something that ran earlier.
Info — your recovery outlook. The heartbeat shows 60 minutes of CU around the timepoint (green = usage, red = limit, yellow = autoscaled; yellow above red = overloaded). The burndown table shows Add/Burndown/Cumulative per experience plus Minutes to burndown — the estimated time to clear the debt if nothing else runs. What to do: use Minutes to burndown to set expectations for when performance recovers.
Yes — this surprises people. CU for failed operations is still counted toward overload, and cancelled operations are reported as failed. A job that fails and retries can still push you toward throttling. What to do: fix failing, retrying jobs rather than ignoring the errors.
No — two separate meters. Your SKU buys compute (CU), which drives throttling and smoothing. Storage is data in OneLake, billed separately per GB. Filling storage does not throttle you, and heavy CU does not use up storage. What to do: slow or throttled → Compute page; rising bill with no slowness → Storage page. Deleting data won't fix throttling.
Normal. Current is the latest snapshot. Billable can be lower if storage was smaller at the start of the period, and Current can even read 0 if workspaces haven't reported for that hour yet. What to do: trust the 30-day trend charts over any single hour's number.
Worth a look — it rarely shrinks on its own. Soft-deleted data is billed at the same rate as active data; the Deletion status column flags workspaces where that's happening. Old data, staging copies and retained items keep counting. What to do: sort by Billable storage %, clean up staging and unused datasets, and check retention on anything you thought was deleted.
Start here. A CU is Fabric's unit of compute; your SKU number is roughly the CUs you get per second (an F2 has 2, an F64 has 64). Every operation costs CU-seconds. Timepoints are 30 seconds long — 2,880 in 24 hours. What to do: once CUs click, the Compute and Timepoint pages become readable.
The concept behind most confusion. Bursting lets a job briefly use more CU than your SKU. Smoothing then spreads that cost forward — 5–64 minutes for interactive work, 24 hours for background — so short spikes don't cost a bigger SKU. This is why 100% often causes no pain. What to do: when a number looks alarming, ask whether smoothing is absorbing it or has run out of runway; the Throttling chart answers that.
Just context. Interactive operations are things a person waits on (reports, slicers, DAX), smoothed 5–64 min and throttled first. Background operations are unattended work (refreshes, pipelines, Spark, most Warehouse ops), smoothed 24 h and throttled last. What to do: interactive pain → report design and model size; background pain → stagger refreshes and pipelines.
How the "debt" works. When operations use more than the SKU supports in a timepoint (after smoothing), an overage is computed. Overage beyond the 10-minute window becomes carryforward — debt applied to later timepoints. When a later timepoint has spare CU, it pays the debt down: burndown. Throttling continues until carryforward is fully paid. What to do: healthy is carryforward that burns back to zero within the day.
False — the #1 misread. Smoothing plus 10 minutes of overage protection mean you can exceed 100% with zero user impact. Only the Throttling chart tells you if work is actually delayed or rejected. What to do: never scale up on utilisation alone.
False — duration is not cost. Cost is measured in CU-seconds, not wall-clock time; Duration (s) has no impact on throttling. A quick, heavy query can cost far more than a long, light one. What to do: rank by Total CU (s).
False — it lags 10–15 minutes. The moment carryforward starts building, the app is already stale — by the time it refreshes, requests may already be delayed or rejected. What to do: for live alerting, use Fabric capacity events in the Real-Time Hub, or the 100% email alert.
False — wrong meter. Throttling is a compute (CU) problem. Clearing OneLake storage lowers your storage bill but does nothing for throttling. What to do: fix throttling on the compute side — optimise heavy operations, reschedule background jobs, or scale the SKU.
False — in-flight work is safe. Throttling only affects requests submitted after throttling starts; operations already in flight, even long ones, run to completion. What to do: don't panic that a running refresh will be killed mid-way.
Utilisation over 100% is an overage, not automatically throttling. Overage protection lets you use 10 minutes of future capacity with no throttling, and smoothing spreads the rest. Confirm with the Throttling chart before you scale up — if there are no delays or rejections, you're simply using what you pay for.
Red means Fabric started delaying or rejecting work. It runs in stages by how much future capacity you've consumed: interactive delay (10–60 minutes of future usage → 20-second delay), interactive rejection (60 min–24 h → requests refused), and background rejection (over 24 h → everything rejected, including refreshes and pipelines).
Carry forward is compute you overspent that Fabric charges against your future timepoints. When a burst exceeds the 10-minute overage window it becomes carry forward CUs, paid down (burndown) when later timepoints have spare capacity. A little is normal; if it never drains to zero, you're structurally over budget and should optimise or scale.
No. Thanks to smoothing and 10 minutes of overage protection, utilisation can exceed 100% with zero user impact. This is the single most common misread of the app. Always check the Throttling chart, not the utilisation number, before deciding to scale.
Minimum recovery time = ((% − 100) ÷ 100) × the window. A 250% background rejection takes about 36 hours; a 250% interactive rejection about 90 minutes. To recover faster, temporarily increase the SKU or pause and resume the capacity (which resets future usage to zero but triggers a billing event).
No. Your SKU buys compute (CU), which drives throttling and smoothing. Storage is data sitting in OneLake, billed separately per GB. Filling storage does not throttle you, and deleting data will not fix a throttling problem.
This tool is based on Microsoft's official Fabric documentation, last reviewed July 2026:
