Help! Slow PBI Service Loading GCC

[jb217]

Hello, 

I'm working in a GCC client environment and on Thursday, 5/29/2025 the service started running extremely slowly! Reports, Workspace Apps, and visuals taking minutes to load when it usually takes seconds. And this is for everything across the entire tenant, multiple workspaces and objects. 

I'm wondering if something developers did started this since on that day:

1.) We added an excel file source hosted in a sharepoint folder to a few semantic models in one of the workspaces.

2.) We set up scheduled refresh for every three hours on the same 3 semantic models. 

I've read that sharepoint as a source is slow, but the file literally has only like 20 rows...and I also i don't understand how that could affect EVERY REPORT IN THE SERVICE. 

I'm not the fabric admin but am hoping to work with the client to get access to fabric management tool. Could there be too many objects bottlenecking the service/using up too many resources, etc.?

Thanks! 

[jb217 · Accepted solution]

Thanks! ended up using a dataflow to capture the sharepoint file data and it seems to be performing better!

[Anonymous]

Hi @jb217 
Thank you for reaching out microsoft fabric community forum.

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.

Thank you.

[Poojara_D12]

Hi @jb217 

Since Thursday, May 29, 2025, you've observed a significant performance degradation across the entire Power BI environment in your GCC (Government Community Cloud) client tenant, where reports, workspace apps, and visuals are taking several minutes to load instead of the usual seconds. This widespread slowdown is affecting multiple workspaces and report objects, raising concerns that recent development changes might be contributing to the issue. Specifically, on the same day the issue began, your team added a small Excel file (with only about 20 rows) hosted on a SharePoint folder as a data source to several semantic models, and also scheduled those models to refresh every three hours. While it's true that SharePoint can be slower compared to other data sources, the size of your file is minimal, and it wouldn’t reasonably explain degraded performance across unrelated workspaces and reports. However, if these refreshes are running frequently and in parallel—especially in a Premium or Fabric capacity environment with shared compute resources—it’s possible they’re consuming a disproportionate share of the capacity's memory or CPU, which could lead to throttling and affect overall performance. Since you're not yet a Fabric admin, gaining access to tools like the Capacity Metrics App or Fabric Admin Monitoring workspace would be helpful. These tools can provide visibility into memory usage, refresh queues, and query wait times to determine whether the tenant is being bottlenecked by too many concurrent operations or inefficient model configurations. It’s important to rule out broader service-side issues as well, especially in GCC environments, by checking the Microsoft 365 Service Health Dashboard for any reported incidents affecting Power BI.

[GilbertQ]

Hi @jb217 

The potential could be an issue with the overall PBI service, which is causing things to run slowly. If you open it up today and everything is back to normal, it could be a service issue, or as highlighted above, it could be a potential capacity issue.

[SamsonTruong]

Hi @jb217 ,

Your assumption that there may be objects bottlenecking and overutilizing the resources would be my best guess, assuming your organization is using a Fabric capacity. To confirm this, I would reach out to your Fabric capacity admin and have them check the Fabric Capacity Metrics App to see if any throttling is occurring.

Here is some official documentation on the app: https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app

If this helped, please mark it as the solution so others can benefit too. And if you found it useful, kudos are always appreciated.

Thanks,

Samson