Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now

Reply
tobny76
Helper I
Helper I

Monitoring - Fabric Capacity Metrics and Get-PowerBIActivityEvent

Hi!
In the "Fabric Capacity Metrics" app I can see some queries using alot of CU.
I'm would like to figure out where they are coming from. I can see the dataset but I need to figure out the visual/report causing this.
I have tried to export all activities with Get-PowerBIActivityEvent but it looks like I can't find the information in the log.
Is this because this is an embedded capacity?
If I am running a report against this dataset in Power BI service I can see info about this,
but I think the queries in this are coming from embedded visuals on a webpage. Is this not logged in the Activity Event?
How can I find more info about where the query are coming from and how does the query look like?

 

 

tobny76_0-1756728710739.png

 

1 ACCEPTED SOLUTION
rohit1991
Super User
Super User

Hi @tobny76 

The Capacity Metrics app will only tell you that a dataset is consuming a lot of capacity, but it won’t show which visual or embedded report is behind it. That’s why you don’t see the detail in Get-PowerBIActivityEvent  those logs mainly capture activity from Service users, not always embedded workloads.

A couple of things you can try:

  • For normal Power BI Service reports >> the activity logs should show “QueryData” events with report and user details.
  • For embedded capacity >> queries triggered from embedded visuals usually won’t show in ActivityEvent. In this case, use the Capacity Metrics app together with Log Analytics (if you have it enabled) to see which dataset/operation is heavy.
  • To get the actual query text >> run Performance Analyzer in Desktop or capture it in DAX Studio against the dataset. That way you can map the expensive query back to a visual.

So in short: ActivityEvent won’t expose embedded queries, you’ll need to use Capacity Metrics/Log Analytics for usage patterns and Performance Analyzer/DAX Studio to see the actual query.


Did it work? ✔ Give a Kudo • Mark as Solution – help others too!

View solution in original post

2 REPLIES 2
rohit1991
Super User
Super User

Hi @tobny76 

The Capacity Metrics app will only tell you that a dataset is consuming a lot of capacity, but it won’t show which visual or embedded report is behind it. That’s why you don’t see the detail in Get-PowerBIActivityEvent  those logs mainly capture activity from Service users, not always embedded workloads.

A couple of things you can try:

  • For normal Power BI Service reports >> the activity logs should show “QueryData” events with report and user details.
  • For embedded capacity >> queries triggered from embedded visuals usually won’t show in ActivityEvent. In this case, use the Capacity Metrics app together with Log Analytics (if you have it enabled) to see which dataset/operation is heavy.
  • To get the actual query text >> run Performance Analyzer in Desktop or capture it in DAX Studio against the dataset. That way you can map the expensive query back to a visual.

So in short: ActivityEvent won’t expose embedded queries, you’ll need to use Capacity Metrics/Log Analytics for usage patterns and Performance Analyzer/DAX Studio to see the actual query.


Did it work? ✔ Give a Kudo • Mark as Solution – help others too!

It was what I thought.
We don't have "Log Analytics" enabled today.
What's the cost for using that?

Helpful resources

Announcements
Fabric Data Days Carousel

Fabric Data Days

Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!

October Power BI Update Carousel

Power BI Monthly Update - October 2025

Check out the October 2025 Power BI update to learn about new features.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.