Microsoft Fabric Capacity Monitoring
Microsoft keeps 14 days of Fabric capacity history. Your budget cycle is 12 months.
Datalogz keeps the capacity history Microsoft discards, and tells you which assets are spending it.
Fabric did not just rename Premium
It changed the unit you are billed in, the app you monitor with, and the way the platform behaves when you run out.
Unified capacity management
Tenant and capacity administration consolidated under one platform.
A new pricing model
F-SKUs measured in Capacity Units, replacing P-SKUs and v-cores.
A different metrics app
The Fabric Capacity Metrics App replaces the Premium version.
Interactive and background operations
Consumption splits between user-driven and scheduled work.
Throttling, smoothing, and bursting
Spikes are spread and deferred, which changes what a daily number means.
What the native Metrics App cannot tell you
Five things it does not do are the five things a capacity owner needs most.
History stops at roughly 14 days
No backfill. A day that ages out is gone permanently.
One capacity at a time
No side-by-side view, so you open each capacity in turn.
No grouping by department, owner, or domain
Consumption is reported by workspace ID. Nobody budgets by workspace ID.
No path from a spike to the asset that caused it
You can see the capacity hit its ceiling. Finding what did it is manual, every time.
Nothing tells you when it happens
No alerting. You find out when someone complains a report is slow.
Consumption you can trace, group, and act on
Capacity data captured daily, retained indefinitely, and joined to inventory you already hold.
Complete capacity history
Microsoft keeps 14 days. Datalogz keeps the full history.
Every capacity in one view
Every capacity ranked side by side, with SKU and region.
Noisy neighbor detection
Identifies which asset caused the throttling, and who owns it.
Throttling and rejection tracking
Distinguishes an undersized capacity from a single runaway refresh.
Consumption by team, department, and owner
Grouped by your org chart, not by workspace ID.
Cost against your SKU commitment
An F-SKU costs the same whether you use it or not. Idle capacity is money already committed.
Monitors and alerts
Alerts routed to the asset owner and tracked through to resolution.
Reading capacity by the org chart, not the workspace ID
A Fortune 500 energy utility was hitting 100 percent capacity alerts three or four times a day. Ninety percent of the reports causing it belonged to individual business units.
The native tooling could tell them the capacity was saturated. Not which operating company was saturating it.
Datalogz resolved each workspace to its operating company and department through their existing directory, then named the four accounting for most of the consumption. That resolution is the whole feature.
The person who notices the throttling is rarely the person who owns the budget for it.
Department-level grouping gives the operator a number the budget owner can act on.
Three steps, nothing to install
Consent an app registration
Read-only access to the Capacity Metrics semantic model, granted by your Fabric admin.
Collect daily, retain indefinitely
Capacity data is pulled and stored every day, well past the point Microsoft drops it.
Join to inventory you already have
The Fabric item ID is already your asset ID in Control Tower.
How the numbers are built
Capacity Units do not behave like a normal metric.
A refresh is billed over 24 hours, not when it ran
Fabric spreads background work across the day after it runs, so a spike rarely lines up with the job that caused it. Our reporting accounts for that offset rather than presenting the chart at face value.
Some usage belongs to no asset
Background and system work is not owned by any single item, so the parts never add up to the whole. We report that gap rather than distributing it across your assets and inflating each one.
Idle capacity still costs you
An F-SKU carries the same annual cost whether it is fully used or half idle. Pricing consumption against that commitment makes unused capacity visible as spend already committed.
Two questions, two numbers
“Which model should we fix first?” needs a ranking. “What is this costing us?” needs a figure in currency. We report them separately rather than blending them into a single number that serves neither.
Fabric capacity monitoring, answered
Roughly 14 days, with no backfill. Once a day ages out nobody can recover it, which is why connecting earlier is worth more than connecting later.
Consumption is attributed to the item that ran the operation, usually the semantic model behind a report rather than the report a user clicked. That is where the compute actually goes, so it is also where remediation belongs.
Your admin consents to a Datalogz app registration, grants it Viewer plus Build permission on the Fabric Capacity Metrics semantic model, and enables two tenant settings that allow service principals to read capacity data. Datalogz then runs read-only queries against that model on a schedule. Nothing is installed or hosted in your environment, and no inbound network path is opened.
The app is Microsoft's point-in-time view of a single capacity over a fortnight. Datalogz keeps the history, ranks every capacity together, groups by your org chart instead of workspace ID, and alerts the right person when something changes.
Intra-day throttling events
Resolving a saturated day down to the moment of saturation, and the operations refused at that point.
Why it is listed separately
This needs data at a finer grain than Fabric records it. Getting there is an open technical problem, not a queued build.
Why a partial version would be worse than none
Smoothing shows jobs running at moments they were not. Attributing a spike from that view produces a confident answer that is frequently the wrong one.
See where your Capacity Units are going
Thirty minutes against your own estate, with consumption ranked by asset and grouped by department.