How to Stop Power BI Working on It
Nothing grinds your analysis to a halt faster than staring at the dreaded "Power BI is working on it..." message. That little loading dialog is a sign that your report is struggling to fetch, calculate, or display your data. This article will walk you through the most common reasons your Power BI report is slow and give you actionable steps to troubleshoot them, from optimizing your data model to writing more efficient DAX code.
Why Is Power BI "Working On It?"
First, it's important to understand what's happening behind the scenes. When you see this message, Power BI isn't frozen or broken. It’s actively processing a request. Every time you slice, filter, or open a report page, each visual sends one or more queries to the data model. The "working on it" message simply means one or more of those queries is taking a long time to return a result.
The most common culprits behind slow queries include:
- A bloated data model: Importing too many unnecessary columns or rows of data.
- Inefficient data relationships: A complex, messy web of table connections instead of a clean structure.
- Badly written DAX measures: Formulas that perform heavy calculations in an inefficient way, especially on large tables.
- Overly complex visuals: A report page with dozens of visuals, or custom visuals that are not well-optimized.
- Slow DirectQuery source: When using DirectQuery, every interaction queries the underlying database. If that database is slow, your report will be slow.
The trick is figuring out which of these is causing your problem. Your first step should always be to diagnose the issue with a built-in tool.
Your First Stop: The Performance Analyzer
Before you start randomly changing your measures or deleting visuals, use Power BI's Performance Analyzer to pinpoint exactly what's taking a long time. It records the processing time for every visual on your report page, breaking it down into specific components.
Here’s how to use it:
- Go to the View tab in Power BI Desktop.
- Click on Performance Analyzer to open the pane.
- Click Start recording.
- Now, interact with your report as you normally would. Click on a slicer, refresh a filter, change pages, or click Refresh visuals in the Performance Analyzer pane to run all queries on the current page.
As you use the report, the pane will fill up with data. You'll see a time breakdown for each visual, which you can expand to see more detail:
- DAX Query: This is the time it took the engine to execute the DAX query sent by the visual. If this number is high, your measure or data model is the bottleneck.
- Visual display: The time it took for the visual to render on the screen. A high number here might point to a complex custom visual or having too many data points to draw (like a scatterplot with 100,000 dots).
- Other: This includes time waiting for other operations to complete. It's often high if the UI is waiting on other visuals to finish loading.
Sort the list by Total time (ms) in descending order to see your worst offenders at the top. This gives you a targeted list of visuals and DAX queries to investigate.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
Optimize Your Data Model
An efficient data model is the foundation of a fast Power BI report. If your queries from the Performance Analyzer are slow, your data model is often the first place to look. A lean and well-structured model allows the DAX engine to perform calculations much more quickly.
1. Reduce the Size of Your Data
Larger models consume more memory (RAM) and make query processing slower. Do not import columns and rows you don’t actually need for your report.
- Remove Unnecessary Columns: In Power Query Editor (click "Transform data" in the Home tab), go through each table and remove any columns that aren't used in visualizations or measures. This is especially true for columns with high cardinality (many unique values), like primary keys (e.g.,
OrderID) or timestamps with high precision. These columns are terrible for compression and slow down your model. - Filter Unnecessary Rows: If your report only needs data from the last two years, filter out the older data in Power Query. Why load 10 million rows of data when your report only ever analyzes the most recent 2 million?
Your goal is to make the dataset as "thin" and "short" as possible without losing the information needed for analysis.
2. Simplify Your Table Relationships
The ideal structure for a Power BI data model is a star schema. In this model, you have a central fact table (containing numbers and keys, like sales amounts and product IDs) connected to multiple dimension tables (containing descriptive attributes, like product names, dates, and customer details).
- Avoid Bi-Directional Relationships: Unless you have a specific and well-understood reason, stick to single direction relationships (from the dimension table to the fact table). Bi-directional relationships can create ambiguity and dramatically slow down query performance.
- Look for "Snowflaking": Sometimes, dimension tables are connected to other dimension tables, a structure called a snowflake schema. While valid, it’s often more efficient in Power BI to denormalize these into a single, flat dimension table using merges in Power Query.
A simple star schema with one-to-many, single-direction relationships is the fastest structure for the Power BI engine.
Write Better DAX Measures
The Performance Analyzer often points to a slow "DAX Query." This means your formula itself is inefficient. Even with a perfect data model, a poorly written DAX measure can bring your report to a grinding halt.
1. Use Variables (VAR) to Avoid Redundant Calculations
Variables are one of the most effective tools for optimizing DAX. You use a variable to store the result of an expression, which you can then reuse multiple times within the measure. This prevents Power BI from having to calculate the same result over and over again.
Slow DAX (No Variables):
Gross Profit Margin =
DIVIDE(
([Total Sales] - [Total Cost]),
[Total Sales]
)In the formula above, Power BI has to calculate [Total Sales] twice. In a simple case like this, it might not matter, but if [Total Sales] were a complex measure, the impact would be huge.
Fast DAX (With a Variable):
Gross Profit Margin =
VAR a = [Total Sales]
RETURN
DIVIDE(
(a - [Total Cost]),
a
)Here, [Total Sales] is calculated just once and its result is stored in the variable a. Not only is this faster, but it’s also much easier to read and debug.
2. Avoid Entire Tables as Filters
A common mistake in CALCULATE is using a full table as a filter condition, especially with functions like FILTER. Filtering entire tables forces the engine to scan every single row, which is incredibly slow on large datasets.
Slow DAX (Filtering a full table):
Red Product Sales =
CALCULATE(
[Total Sales],
FILTER(
'Product',
'Product'[Color] = "Red"
)
)The code works, but it’s inefficient because FILTER creates a temporary copy of the entire Product table in memory before filtering it.
Fast DAX (Filtering just the column):
Red Product Sales =
CALCULATE(
[Total Sales],
'Product'[Color] = "Red"
)This version is far more efficient. Using a direct filter on the column is known as a "filter argument," and it leverages the internal engine optimizations for speed. Use full-table scans with FILTER only when absolutely necessary.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
3. Use Iterator Functions (SUMX, COUNTX, etc.) with Caution
Iterator functions like SUMX are powerful, but they work by iterating over a table row by row and performing a calculation. On a table with millions of rows, this can be extremely slow.
If you can achieve the same result with a simple aggregation function like SUM, do that instead.
For example, if you wanted total sales, this SUMX is unnecessary and slow:
Total Sales with SUMX = SUMX('Sales', 'Sales'[OrderQuantity] * 'Sales'[UnitPrice])It’s better to create a calculated column in your data table for Line Total = 'Sales'[OrderQuantity] * 'Sales'[UnitPrice] in Power Query or at the table view, then just use a simple SUM:
Total Sales = SUM('Sales'[Line Total])The aggregation function is almost always faster than the iterator equivalent for simple aggregations.
Streamline Your Report Design
Even with a well-performing model and great DAX, the report page itself can be the source of a slowdown.
- Switch Between DirectQuery and Import Mode: If you're using DirectQuery, you're limited by the speed of your source database. Import mode stores a compressed copy of the data inside your PBIX file, which makes user interaction blazing fast. Unless you absolutely need real-time data, using Import or a Composite model (a mix of both) is usually the best choice for performance.
- Reduce the Number of Visuals: Every visual on a page sends at least one query. A page with 30 different cards, charts, and tables is sending 30+ queries every time it renders. Consolidate visuals where possible or break complex dashboards into multiple, focused pages.
- Limit Slicers with Many Values: Slicers are amazing, but a slicer on a field with thousands of unique values (like
Customer NameorProduct ID) can be very slow to load. Consider switching to a dropdown slicer or using the Filter Pane instead, which is often more performant.
Final Thoughts
Seeing the "working on it" message in Power BI can be maddening, but a slow report is almost always fixable. By starting with the Performance Analyzer to diagnose the issue, then methodically optimizing your data model, cleaning up your DAX, and simplifying your report design, you can eliminate the bottleneck and get back to analyzing your data.
While mastering Power BI optimization is a valuable skill, the high learning curve of DAX and data modeling can be a huge time sink. Many teams don't have the time to become BI experts. For those workflows, we built Graphed to remove the complexity. You can connect your data sources in seconds and then use simple, plain English to build real-time dashboards - no DAX required. Instead of spending hours writing and optimizing queries, you can just ask, "Show me traffic source vs revenue from Google Analytics for this quarter," and get an interactive chart in seconds.
Related Articles
How to Create Facebook Ads API for Claude Code
Create a Meta Marketing API access token that never expires, using a system user, so Claude Code can pull Facebook ad reports and manage campaigns.
ClickHouse vs Postgres: When to Switch to Columnar
Comparing ClickHouse vs PostgreSQL means matching storage architecture to workload. Row storage wins for transactions. Columnar wins for scan-heavy analytics.
Google Ads for Orthodontists: Get More Booked Consults
Most orthodontic Google Ads campaigns waste money on low-intent searches. The problem is structure, not the platform.