11 Ways to Debug DAX Formulas in Power BI

An Ancient Solution for Your Modern DAX Problems.

May 14, 2026

Dark tech-themed banner with white text "Dax Formulas Debugging" and orange subtext "in Power BI," overlaid on a blurred digital network of blue lines and orange light nodes

DAX evaluates formulas differently than most programming languages.

In Python or SQL, you set breakpoints, print intermediate values, or step through code line by line. DAX does not offer a built-in debugger inside Power BI Desktop. Another problem is the evaluation context.

The same DAX measure can produce different results depending on where you place it in a report.

Error Handling:

DAX provides several functions to deal with errors and unexpected values:

DIVIDE(): Use it for all division operations instead of the / operator.
COALESCE(): Returns the first non-blank value from a list of expressions. Use it as a replacement for nested IF/ISBLANKs.
IFERROR(): Returns an alternate result if an error occurs (use sparingly for performance reasons).
IF(): Use it only when you want to check certain conditions.

Variables:

Variables are the simplest starting point for debugging.

Rewrite your DAX expression and assign each intermediate calculation to a named variable, then modify the RETURN statement to inspect specific variable values one by one.

Example:

Delta Avg 2 :=
VAR CurrentValue = [Avg Transaction]
VAR ReferenceValue =
    CALCULATE ( [Avg Transaction], ALLSELECTED ( ‘Date’ ) )
VAR CurrentDelta = CurrentValue - ReferenceValue
VAR Result =
    DIVIDE ( CurrentDelta, ReferenceValue )
RETURN
    Result

When this measure produces unexpected results, you can change the RETURN statement to display one variable at a time.

You can also assign parts of your calculation to VAR and then return a chosen variable. For example, calculate parts of a ratio in separate VARs and change the final RETURN to output one VAR.

After you identify the problem, restore the original RETURN.

For table results, use the TOJSON or TOCSV functions to convert a table variable into a string. These functions output the entire table as JSON or CSV text, which you can display in a report to inspect row values. For example, return return TOJSON(TableVariable) inside a card visual to see the contents of that table.

Virtual Table Inspection with CONCATENATEX:

Use CONCATENATEX to visualize the contents of virtual tables that exist only during the execution of a measure. FILTER, DATESBETWEEN, and SUMMARIZE functions create these tables.

A measure must return a single scalar value, so you cannot display a virtual table in a report visual. CONCATENATEX solves this problem and joins the values from a column of the virtual table into a single text string.

Here is how to do that:

Define the virtual table as a variable within the measure.
Use CONCATENATEX as the final result in the RETURN statement.
Specify the table variable, the column to display, and the delimiter.

For example, if a rolling average calculation returns incorrect values, then you can display the list of dates in the virtual table and see if the range is calculated correctly.

Debug Dates =
VAR DateRange = DATESBETWEEN(’Calendar’[Date], [StartDate], [EndDate])
RETURN CONCATENATEX(DateRange, ‘Calendar’[Date], “, “)

If your rolling 7-day total includes only six days, CONCATENATEX will show the dates inside DateRange.

Use COUNTROWS when you only need the number of rows in a virtual table:

Debug Row Count = 
COUNTROWS(Sales, Sales[Amount] > 1000)

Combine these techniques inside your main measure during debugging, then remove them after you confirm the virtual table contains the correct rows.

Inspect Filter Context with ALL, REMOVEFILTERS, ALLSELECTED:

Unexpected results sometimes come from filter contexts you did not know existed.

Slicers, page-level filters, visual-level filters, and cross-filtering from other visuals modify the filter context that evaluates your measure. Use these functions inside CALCULATE to test how filter removal or preservation affects results. Compare outputs with and without filters to isolate context issues.

To test if filters cause the issue, create a version of your measure that strips them away:

Total Sales No Filters = CALCULATE(SUM(Sales[Amount]), ALL(’Calendar’))

ALL() removes every filter from the Calendar table. If this version returns the expected total while the original does not, you know the Calendar table carries an active filter that alters your result.
REMOVEFILTERS() works like ALL() as a CALCULATE modifier, but it does not return a table or column. It only modifies filter context. Use it when you want to remove filters from a specific column rather than an entire table:

Total Sales No Year Filter = 
CALCULATE(SUM(Sales[Amount]), 
  REMOVEFILTERS(’Calendar’[Year]))

ALLSELECTED(): Removes filters created by the current visual or grouping but keeps filters from external slicers. If your denominator returns the same value for every row in a visual, check if you used ALL when you should have pick ALLSELECTED.
ALLEXCEPT(): Removes all filters except those specified.

Context Transition Debugging:

Context transition happens when CALCULATE or CALCULATETABLE transforms an active row context into an equivalent filter context.

Any reference to a measure inside an iterator implicitly invokes CALCULATE, so context transition happens whenever you call a measure within SUMX, FILTER, or any other iterator.

Inside SUMX, you might expect a measure to sum the entire table. Instead, context transition filters the table to the current row, changing the result.

To debug context transition, replace the measure reference with an explicit CALCULATE. For example, if you suspect context transition filters too aggressively, test the inner expression without a measure reference:

NoTransition =
SUMX (
    Products,
    SUM ( Sales[Quantity] )
)

Compare this against:

WithTransition =
SUMX (
    Products,
    CALCULATE ( SUM ( Sales[Quantity] ) )
)

The second version applies context transition because of the explicit CALCULATE. If the results differ, context transition is the cause.

When you need context transition but you want to preserve existing filters, wrap the filter argument in KEEPFILTERS. Without KEEPFILTERS, the context transition overwrites any existing filter on the same columns.

Data‑Model Driven Debugging:

Many DAX issues come from how the model slices the data. For example, measure works for some dimensions but not for others because of incorrect relationships or ambiguous filters.

Use Simple Context Visuals to debug and place the measure on:

A single‑card visual with no filters.
A table with one dimension (for example, Date[Year]).
A matrix with two dimensions (Year, Category).

If the measure changes when you add a dimension, it signals that filter context or relationships are moving in a wrong direction.

2. Check Relationships and Filters:

Open the model view in Power BI Desktop and review:

The direction of the relationships.
If USERELATIONSHIP function activates inactive relationships.

Then you can use a measure on a table as a dimension to verify that Power BI shows the correct number of rows after applying each filter.

Count Rows =
COUNTROWS(’FactTable’)

Performance Analyzer:

The Performance Analyzer shows how long each visual takes to load and a DAX query behind it.

In Power BI Desktop, open the View ▶ Performance Analyzer pane, start recording, and refresh visuals.

Each visual query appears in the log with its query time. You can click “Copy Query” and paste it into a DAX query window in DAX Studio or the DAX Query View.

Each visual entry breaks down into three time categories:

DAX Query: The time spent executing the query that feeds the visual.
Visual Display: The time spent rendering the chart, table, or matrix on screen.
Other: Overhead time, including waiting for other visuals to finish.

If the DAX Query portion takes most of the total duration, the bottleneck is in your data model or your DAX formula.

If Visual Display dominates, the visual contains too many data points or uses a format that takes time to load.

For Other category, the page contains too many visuals competing for resources.

The Performance Analyzer does not tell you which line of DAX is slow, but it identifies which visual is slow and gives you the query to investigate.

DAX Query View:

Power BI Desktop has a feature called the DAX Query View. You can find it on the left panel, below the model view.

The DAX Query View gives you a space to write, test, and analyze DAX queries without modifying report visuals or the data model. You can run queries to return full tables and inspect the intermediate outputs that measures do not show.

A measure returns a single scalar value inside a visual, while a query returns a table of results.

To evaluate a measure, right-click it in the DAX Query View pane and select Quick Queries > Evaluate. To see both the formula and the result together, choose Quick Queries > Define and Evaluate. The pane splits to show the DAX expression on one side and the evaluated output on the other. When a measure depends on other measures, you can select Quick Queries > Define with References and Evaluate.

If a top-level measure returns an unexpected number, you can trace backward through its lineage to find the sub-measure that introduced the error.

You can modify a measure temporarily and test the change without saving it to the model. You can edit the DAX code inside the query view, run it, and compare results.

Once you confirm the fix works, click Update Model to apply the change.

Evaluation Logging with EVALUATEANDLOG:

EVALUATEANDLOG records intermediate results of a DAX expression to the DAX evaluation log.

The system outputs these results in JSON format. Wrap a variable or expression inside EVALUATEANDLOG, then pick the log with an external tool. The log shows the result for each combination of dimensions in the visual.

To debug a ratio measure, wrap the numerator and denominator with EVALUATEANDLOG:

Delta Avg =
DIVIDE (
    EVALUATEANDLOG ( [Avg Transaction], “Numerator” ),
    EVALUATEANDLOG (
        CALCULATE ( [Avg Transaction], ALLSELECTED ( ‘Date’ ) ),
        “Denominator”
    )
) - 1

When you refresh the visual, DAX debug output shows one log entry for each granularity level in the visual.

If the visual groups by year and brand, the log contains separate entries for the year-brand combinations, the year totals, the brand totals, and the grand total.

The DAX engine evaluates measures in blocks, and the log shows aggregated evaluations rather than cell-by-cell.

EVALUATEANDLOG slows down report execution, so remove it from your measures before publishing to Power BI Service.

DAX Studio:

Query plan Analysis:

Power BI executes DAX queries by two engines: the Storage Engine (SE) and the Formula Engine (FE).

Efficient queries push as much work as possible to the multi-threaded and optimized Storage Engine. When the FE does most of the work (especially row-by-row iteration) It slows down the execution.

How to Analyze:

Use DAX Studio’s Server Timings and Query Plan features.
Look for high FE time, many SE queries, or CallbackDataID operators.

Problem areas:

Iterators (SUMX, FILTER) over large tables.
Nested CALCULATE or FILTER patterns.
Missing or inefficient relationships.

How to optimize formulas:

Replace FILTER with direct Boolean predicates in CALCULATE.
Use variables to store intermediate results and avoid repeated evaluation.
Pre-aggregate data in Power Query or with calculated columns when appropriate.
Remove unused columns and reduce cardinality in the model.

Example:

-- Inefficient
CALCULATE([Total Sales], 
  FILTER(ALL(Products), Products[Category] = “Electronics”))

-- Efficient
CALCULATE([Total Sales], Products[Category] = “Electronics”)

Tabular Editor:

Tabular Editor can run through a measure expression line by line. You can pause the calculation of a single cell to see what is happening inside the formula.

Start debugging from Pivot Grid or a DAX query. Create a Pivot Grid, add your measure, and set any filters or rows; then right-click a value cell and select [Debug this value], or paste a DAX query from the Performance Analyzer into a query window, execute it, right-click a cell in the result, and select [Debug].

Step-Through Navigation: You can move through your code line-by-line with [Step Into] (F11) or [Step Over] (F10).
Evaluation Context Panel: It displays the full stack of active filters affecting your calculation. You can toggle individual filters on and off to see how the result changes.
Locals and Watch Panels: Locals panel lists every variable and sub-expression in your formula with its current value. You can type in any custom DAX expression to test it against the current filter context on the fly with the Watch panel.
Call Tree: It provides a visual map of the calculation flow, highlighting which branches of a formula (IF or SWITCH statement) are being executed and which are not.

Copilot AI:

Microsoft integrated Copilot into the DAX Query View.

You can interact with it with natural language to explain or fix your code. Select a block of DAX and ask Copilot to describe what it does. If a formula returns an error, you can ask it to find the mistake.

The system will analyze the syntax and the relationship between your tables to suggest corrections or create new measures.

Best practices:

Use descriptive variable names.
Limit each variable to a single logical step.
Use the Star Schema data model.
Use // for single-line comments in DAX
Simplify DAX code. Avoid deeply nested functions and complex calculations.
Use Measures Instead of Calculated Columns.
Test DAX Expressions in Isolation.
Use Power Query to normalize text columns, split multi-value fields, create lookup dimensions, and convert data types.
Use version control.
Use DIVIDE for all division operations.
Use COALESCE instead of nested IF/ISBLANK.
Use IFERROR only for edge cases.

Buy me a coffee

Subscribe for more Power BI guides.
What is the hardest DAX concept for you?
Let me know in the comments👇

BIWave Substack

Discussion about this post

Ready for more?