Forum Discussion
Helper IVMonitor Power BI Report Performance
I am a Fabric administrator and with my permissions I can utilize the MS Fabric Capacity Metrics app. However, regular users do not have access to this data. I have a report developer who is requesting data on performance metrics for his report. Data such as how long did it take a report to load. How many CUs did an object use. Is there any way I can make this information available? I have a report I created that access the Power BI Activity log and shows audit data but it does not have the performance information he is requesting. He would like this for performance tuning and optimization. I checked out the reports in the Admin Monitoring workspace but they do not appear to have performance data.
Hi Lorenz33
There now is an option to use the Capacity monitoring getting the real time events which you can then store in a lake house and create a power BI report which then can be shared to the users. Here is my blog post and how to set this up.
https://www.fourmoo.com/2026/09/09/monitoring-microsoft-fabric-capacity-usage-with-operation-events/
7 Replies
- GilbertQ
Super User
Hi Lorenz33
There now is an option to use the Capacity monitoring getting the real time events which you can then store in a lake house and create a power BI report which then can be shared to the users. Here is my blog post and how to set this up.
https://www.fourmoo.com/2026/09/09/monitoring-microsoft-fabric-capacity-usage-with-operation-events/
Lorenz33Hi GilbertQ
Your suggestion looks promising for what we need. We need the events for up to 3 workspaces and need Power BI reports created for a developer who is not a Fabric admin. Looking at the data we should be able to isolate the workspcaces from a workspace ID. However, I see information on the source and subject. The KQL table has 8 columns: time, specversion, source, dataschemaversion, type, subject, id, and data.
The data column has performance data that can be used. Is it possible to load the KQL table into a lakehouse and have the data column split into its different components which can be reported on?
- ShivekMaharaj
Community Champion
Hi Lorenz33,
Yes - you can load that data into a Lakehouse and split the data object into individual columns, but for this particular use case I would first consider doing the flattening directly in KQL.
The eight columns you are seeing are the CloudEvents envelope for the newer Fabric Capacity Operation Events feed. Microsoft's current Capacity Operation Events schema shows that the nested data object already contains fields such as:
- workspaceId / workspaceName
- itemId / itemName / itemKind
- operationName
- durationMs
- capacityUnitMs
- throttlingDelayMs
- status
- identity information
So you don't actually need to extract the workspace ID from subject unless you want to. The data object already provides it directly.
For example, you could flatten the events in KQL with something along these lines:
<your_table>
| where type == "Microsoft.Fabric.CapacityOperationEvents.Operation"
| extend d = parse_json(data)
| project
time,
workspaceId = tostring(d.workspaceId),
workspaceName = tostring(d.workspaceName),
itemId = tostring(d.itemId),
itemName = tostring(d.itemName),
itemKind = tostring(d.itemKind),
operationName = tostring(d.operationName),
durationMs = tolong(d.durationMs),
capacityUnitMs = todouble(d.capacityUnitMs),
throttlingDelayMs = tolong(d.throttlingDelayMs),
status = tostring(d.status),
identityValue = tostring(d.identityValue)and then restrict it to the three workspaces you want:
| where workspaceId in ("workspace-1", "workspace-2", "workspace-3")
Microsoft documents the KQL parse_json() function for exactly this type of JSON/dynamic expansion.
There is also a bag_unpack option that can automatically turn the properties of a dynamic object into columns, although for a reporting model I would normally project the specific columns I need. That gives you a stable schema and avoids unnecessary expansion of every property.
For the Power BI report, you may not actually need to move the data into a Lakehouse first. Power BI can connect directly to a Fabric KQL database using either Import or DirectQuery, so one possible architecture is:
Capacity Operation Events → Eventhouse/KQL → flatten/filter with KQL → Power BI
That would be my first choice if the purpose is mainly to give the developer a monitoring report.
If you do want a Lakehouse copy - for example, because you want to join this telemetry with other historical data - Fabric Data Factory can also use a KQL Database as the source of a Copy activity, including a KQL query as the source, and write the flattened result into a Lakehouse table.
One useful detail for your original requirement is that capacityUnitMs is specifically documented as the CU consumption attributable to that operation/item/workspace, while durationMs gives you the elapsed operation duration. That should let you build exactly the type of developer-facing performance report you were describing.
If the three workspaces are all on the same Fabric capacity, I would capture the capacity-operation stream once and filter it by workspaceId rather than building three separate solutions.
One caveat: Fabric Capacity Operation Events are currently documented as Preview, so I would take that into account if this is intended to become a long-term production monitoring dependency.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- v-aatheeque
Community Support
Hi Lorenz33
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.
- v-aatheeque
Hi Lorenz33
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.
- ShivekMaharaj
Hi Lorenz33,
Bipin-Lala has covered the main monitoring options very well. One current capability I would add because it may solve your immediate access problem is that the Fabric Capacity Metrics report itself can be shared with non-admin users.
Microsoft's current Fabric Capacity Metrics documentation states that a capacity admin is required to install the app, but after installation the capacity admin can share the report with other users in the organization.
That may be the simplest option if your report developer is allowed to see the capacity-level telemetry.
The Metrics app already exposes information such as:
- workspace and item
- operation
- duration
- user
- start/end time
- CU consumption
and the Timepoint / item-detail pages can be useful for identifying which report or semantic-model operations consumed the most compute.One governance point to consider before sharing it is user information. The same Capacity Metrics guidance documents a tenant setting called Show user data in the Fabric Capacity Metrics app and reports, which controls whether names/email addresses are displayed.
I would not, however, build a custom developer report directly on top of the Capacity Metrics semantic model. Microsoft explicitly states that the semantic model supplied with the Metrics app is only supported for use by the reports included in that application; downstream consumption or modification of that model is unsupported.
If you do not want the developer to have visibility into capacity-wide telemetry, I would use Workspace Monitoring instead.
Microsoft's semantic model operation logs expose fields such as DurationMs, CpuTimeMs, ExecutingUser, ItemName, OperationName, and query/event details. That data can be used to create a report scoped to the developer's workspace or semantic models rather than exposing the complete capacity.
There is now also a Semantic Model Monitoring dashboard template, so you can get a developer-facing monitoring experience without having to build the whole solution from scratch.
For individual report tuning, I would still use Performance Analyzer because it shows the breakdown for each visual - DAX query, DirectQuery, visual display and other time - whereas capacity telemetry tells you more about the server/capacity side of the workload.
So I would probably use this split:
Capacity-level CU / operation troubleshooting → share Fabric Capacity Metrics
Developer/workspace-specific historical query performance → Workspace Monitoring
Individual visual/page tuning → Performance Analyzer
That gives the developer useful performance information without relying on the Activity Log, which is primarily auditing data rather than detailed query-performance telemetry.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
