How to Actually Monitor Power BI Report Performance - A Consultant's Field Guide

Every Power BI consulting engagement we run eventually arrives at the same conversation. Someone in finance, operations or sales mentions that the dashboard "takes forever to load". A page that used to open in three seconds now sits on a loading spinner for fifteen. People stop using it. Eventually the report owner pings us and asks if we can "have a look".

That look almost always reveals the same thing. The team built the report, it ran fine for six months, then data volumes grew, a few visuals were added, somebody nested two CALCULATE statements inside a SWITCH and now performance has fallen off a cliff. Nobody profiled anything along the way. There was no baseline. There is no way to know which change caused the slowdown.

This is the part of Power BI work that almost no training course covers properly. Microsoft has good documentation on the performance monitoring tools available in Power BI Desktop, but it reads like a tools reference rather than a method. What I want to do in this post is walk through how we actually use these tools on client engagements, in what order, and what to look for. If you are responsible for a Power BI model that has started to feel slow, this is roughly how we would approach it.

Start with Performance Analyzer because it gives you a triage

The first tool to reach for is Performance Analyzer, built straight into Power BI Desktop under the View ribbon. Open it, click Start recording, then refresh the visuals on the page you care about. What comes back is a list of every visual on the page with a breakdown of where the time went. There are three numbers per visual: DAX query, visual display, and other.

That split matters more than people realise. If the DAX query number is dominant, your problem lives in the model. The query is slow, which usually means a measure is doing too much work, a relationship is causing a fan-out, or you have a calculated column doing something it should not. If the visual display number is dominant, your problem is the visual itself. A custom visual is rendering slowly, or you are asking a single chart to plot ten thousand data points. If "other" is large, you usually have visuals waiting on each other due to filter interactions, or you have hit some quirky bottleneck like a slow image fetch from a public URL.

We had a client in Sydney last year with a report page that took eighteen seconds to render. Performance Analyzer showed that one visual, a custom KPI card from AppSource, was taking thirteen of those seconds on its own. The fix was to drop the custom visual and use a native card with conditional formatting. Took twenty minutes. Saved everyone a useful fraction of their day. Without Performance Analyzer we would have been guessing for hours.

One thing to be aware of. Performance Analyzer does not capture Premium Per User activities or capacity utilisation. If you suspect your problem is related to capacity throttling or noisy neighbours on a shared Premium SKU, you need the Fabric Capacity Metrics app for that. Different tool, different question.

If you would rather have someone else handle the triage, our Power BI consulting team does this kind of analysis as part of any health check engagement.

Use Query Diagnostics when the problem is in Power Query

Performance Analyzer tells you which visual is slow, but it does not tell you anything about what is happening during data refresh. Refresh problems live one level deeper, in Power Query, and the tool for that is Query Diagnostics.

Query Diagnostics in Power BI Desktop lets you record what Power Query is doing while it previews or applies queries. There is also a Diagnose Step function that records detailed evaluation information for each individual step in a query. The output comes back as a Power Query table itself, which means you can apply transformations to it, group it, filter it, and figure out where the time is going.

In real engagements, the most useful thing Query Diagnostics shows us is whether query folding is happening or not. Power Query is meant to push transformations back to the source where it can. If you connect to a SQL Server, filter rows, group columns and project a small result set, Power Query should send all of that as a single SQL statement. When it does, you can refresh huge tables in seconds. When folding breaks - usually because somebody added a custom column or a merge that cannot be translated - Power Query has to pull the whole table into memory and do the work on the desktop machine. Query Diagnostics will show you exactly where that break happens.

The pattern we see most often is well-intentioned transformations that accidentally kill folding. Someone adds an "Added Custom Column" step that uses a complex M expression. Three steps later, performance has collapsed and nobody knows why. Query Diagnostics surfaces it in minutes.

SQL Server Profiler is for the hard cases

When you have used Performance Analyzer to find a slow DAX query, and you want to dig into what the underlying Analysis Services engine is doing, SQL Server Profiler is what you reach for. It is part of SQL Server Management Studio, which you can download free from Microsoft.

The connection process is slightly fiddly. Open your Power BI Desktop report. In PowerShell with admin rights, run netstat -b -n and look for the port being used by msmdsrv.exe. That is the local Analysis Services engine inside your Power BI Desktop instance. In Profiler, start a new trace, choose Analysis Services as the server type, and connect to localhost on that port. Now any query Power BI Desktop runs will show up in Profiler with timing, CPU and event details.

Profiler is also useful when your data source is SQL Server, SQL Server Analysis Services or Azure Analysis Services. You can trace the relational source directly and see the actual SQL being generated by DirectQuery models. This is invaluable when you suspect that Power BI is generating bad SQL - which it does sometimes, especially when relationships are complicated or models mix DirectQuery and Import.

There is a caveat that Microsoft is right to flag. Power BI Desktop's diagnostic port lets external tools make changes to the model, but most of those changes are not supported. If you connect Tabular Editor or DAX Studio or anything else and start modifying things outside of supported operations, you can corrupt your model and lose work. Profiler itself is read-only so it is safe, but the broader category of external tooling needs care.

One useful trick. If your data source is SQL Server, you can save the trace from Profiler and feed it into the Database Engine Tuning Advisor. The Advisor will then look at the actual queries Power BI sent and suggest indexes or statistics that would help. We have used this on a few mid-market client engagements where the SQL backend was the real bottleneck rather than the model. The advisor is not magic, and you should not apply its suggestions blindly, but as a starting point it is often useful.

What we actually do on engagements

Here is the rough order we work in when we get the "report is slow" call.

First, replicate the problem and time it. If the client says fifteen seconds, open the report yourself and confirm. People remember the worst experience, not the average one, and you need a baseline anyway.

Second, run Performance Analyzer on the slow page. Identify which visuals are dominating the time. Note whether the bottleneck is the DAX query, the visual itself, or something else.

Third, if DAX is the issue, pull the slow queries out using the "Copy query" option in Performance Analyzer and run them in DAX Studio. DAX Studio gives you the server timings, the query plan, and the storage engine versus formula engine split. That is usually enough to find the issue. Common culprits are bidirectional filters, calculated columns that should be measures, and measures that scan large tables unnecessarily.

Fourth, if refresh is slow rather than rendering, switch to Query Diagnostics and look for broken folding or expensive transformations.

Fifth, if you are on Premium and you suspect capacity is the issue, look at the Capacity Metrics app.

This sequence is unglamorous but it works. Most performance problems are not subtle. They are usually one or two specific things you can fix quickly once you have measured them.

What we would tell you to do this week

If you are running Power BI inside an Australian organisation and you have never run Performance Analyzer on your most important report, do it this week. Pick the page that gets the most use, open Power BI Desktop, click Start recording in the Performance Analyzer pane, and refresh visuals. Save the result. Now you have a baseline. The next time someone says the report is slow, you can compare.

Most of the engagements we get called into could have been avoided with thirty minutes of profiling work earlier in the report's life. The tools are free, they are built into the product, and they tell you what is wrong with very little ambiguity. The reason they are underused is mostly that nobody teaches people they exist.

If your reports have hit the wall and you want help working through it, our Microsoft Fabric and Power BI specialists do health check engagements specifically for this. We have also written about how to scope a Power BI consulting engagement so you know what to expect when you reach out.

You can read Microsoft's full reference on report performance monitoring at Monitor report performance in Power BI. It is worth bookmarking.