Lesson 2 of 8 · 10 min
Reading the Capacity Metrics App
Most capacity conversations start with an opinion: “Fabric is slow,” “the SKU is too small,” “Spark is eating everything.” The Capacity Metrics app is how you replace opinions with a record of what consumed the capacity, when, and how much.
Install it before you need it. Teams that install it during their first incident spend the incident learning the app instead of reading it.
Install and share it
Capacity admins install the Microsoft Fabric Capacity Metrics app and connect it to the capacities they administer. Share the installed app with the people who will run the weekly review, not only with platform administrators. Workspace owners make most of the decisions that change consumption, so they need to see it.
Check the tenant setting that controls whether user names appear in the app. If it is off, operations show a masked user, which protects privacy but makes it harder to trace who triggered a heavy operation. Decide that deliberately with your privacy stakeholders.
The compute data covers a recent rolling window of about two weeks and usually appears after a short processing delay. If you need a longer history for trends or chargeback, export a summary every week or use the Chargeback app covered in lesson eight.
The four views that matter most
The app has many pages. Four views answer most operational questions.
Utilization
The utilization chart on the Compute page shows consumption as a percentage of the capacity, split into interactive and background. It is the first place to see the shape of a normal day.
Read it in two ways. The background layer is usually a smooth band, because background work is smoothed over 24 hours. The interactive layer is spiky, because it follows people. A rising background band is a planning problem. Sharp interactive spikes are usually a workload problem.
Throttling
The Throttling tab shows three charts: interactive delay, interactive rejection, and background rejection. Each one measures how close the capacity was to that protection stage. A value above 100% on a chart means that stage was active.
This is the only reliable way to say “we throttled.” A utilization spike above 100% is not proof, because bursting and smoothing allow short excursions without any user impact.
Overages and carryforward
The overage views show carryforward being added, burned down, and its cumulative total. Short spikes that add and burn down quickly are normal. A cumulative line that keeps climbing across hours means demand is persistently ahead of supply.
Items and operations
The matrix by item and operation lists workspaces, items, and operation types with their CU (s), duration, users, and counts. Sort by CU-seconds, not duration. A long-running operation can be cheap, and a short one can be expensive.
Add optional columns such as rejected count, failed count, and overloaded minutes when you investigate an incident. The timepoint drill-through shows exactly which operations contributed to one 30-second slice, including smoothed background work that started hours earlier.
Also check storage
The Storage page shows OneLake storage by workspace over time. Storage does not consume CUs, but it is part of the bill. Look for workspaces that grow every day without a matching business reason, and for soft-deleted data that has not yet aged out.
What a healthy capacity looks like
There is no universal target, but healthy capacities tend to share a few traits:
- The background band is steady and well below 100%, which leaves room for interactive peaks.
- Interactive spikes happen during working hours and recover quickly.
- Throttling charts stay below 100%, or cross it rarely and briefly.
- The top ten items account for a large share of consumption, and each has a known owner.
- Nobody is surprised by the top consumer.
A capacity that never goes above 20% is also unhealthy, just in a different way. It is costing more than it needs to.
Exercise: record a baseline
Pick the most recent full week without a known incident and record this baseline. You will reuse it in every later lesson.
| Measure | Value |
|---|---|
| SKU and region | |
| Typical weekday background percentage | |
| Typical weekday interactive peak percentage, and when it happens | |
| Highest interactive delay percentage in the week | |
| Any interactive or background rejection, with time | |
| Top five items by CU-seconds, with owner and operation type | |
| Share of total CU-seconds from the top five items | |
| Overnight and weekend utilization | |
| OneLake storage total and weekly growth |
Then write one sentence for each top-five item: what business purpose it serves and how often its data actually needs to change. You will use those sentences in lesson four.
Carry this forward
A baseline tells you what normal looks like. The next lesson uses it to handle the abnormal: a throttling incident, investigated from the capacity down rather than from the complaint up.