This is the 4th part of our Fabric Capacity Management series. If you haven’t yet, check out the earlier articles:
- Part 1: Causes and Consequences of Capacity Overloads
- Part 2: Actions to Take During Capacity Throttling
- Part 3: Alerting Users During Capacity Throttling
Monitoring tools are essential for effective management of Microsoft Fabric capacities. The native solution provided by Microsoft — Fabric Capacity Metrics — offers insight into the most important metrics, such as:
- Current resource consumption levels
- Throttling status
- CU (Capacity Unit) usage by specific artifacts over time
However, this built-in report is designed primarily for Fabric administrators. It gives a very technical, tenant-wide view — with no Row-Level Security (RLS). That means any user with access can see everything, making it unsuitable for sharing with business users. It also has several other limitations:
- Data is available only for the last 14 days
- The report can show only one capacity at a time
- Performance can suffer due to the use of Direct Query
- It’s not always clear which items are causing issues, or what those issues are
Another option is FUAM (Fabric Unified Admin Monitoring), a powerful, community-developed framework for centralized monitoring of your Fabric environment. It gathers historical data, capacity insights, activity tracking, and more. Built using Fabric artifacts, it collects data from sources like the Fabric API and Fabric Capacity Metrics. It’s modular, customizable, and very detailed.
However, it comes with trade-offs:
- No built-in security layer (though this can be custom-developed)
- Runs on Fabric — so it consumes CUs from your capacity
- Best suited for admins and Fabric platform teams due to its complexity and depth
While both Fabric Metrics and FUAM provide valuable overviews, they are not suited for self-service users. But what if we empowered business users to monitor their own impact on capacity?
What Would a Self-Monitoring Tool for Business Users Need?
To make self-service monitoring possible, such a tool should include:
- Security layer — Users should only see data from workspaces where they’re developers
- Clear interface — Easy navigation with quick insight into key metrics
- Key data points, such as:
- CU consumption per item
- Operation types (refreshes, queries, etc.)
- Responsible users
- Interactive spikes indicating report or DAX performance issues
- How item usage compares to others in the tenant
- Trends over time
And all of this should include historical data, with flexible filtering by workspace, item, user, or operation type. It would also help to provide visibility into overall capacity status — including current loads, past overloads, and their causes.
Why It Matters
Sound interesting? Let’s look at the potential benefits.
A self-monitoring tool could significantly increase user awareness of how their actions affect shared capacity — and, in turn, other users. Quick access to performance indicators would highlight which items need optimization and what kinds of problems exist:
- Is the data refresh too heavy?
- Is a report using too much CU due to poor design or inefficient DAX?
- Are changes made by developers improving or worsening performance?
This kind of observability shifts some responsibility back to the user — encouraging better development practices, driving optimization, and improving overall capacity usage. It could help reduce overloads, lower costs, and build a stronger culture of data awareness.
What Fabric capacity monitoring tools are you using in your organization? More insights coming soon.
#MicrosoftFabric #Fabric #Optimization #MicrosoftFabricOptimization #SelfService #SelfServiceBI #CitizenDeveloper #FabricMonitoring #FabricObservability #FabricCapacityMetrics #FUAM
Leave a Reply