A Power BI report can look finished while its totals disagree with the source, its measures fail under a slicer, or its access rules expose more than intended. A health check gives the team a repeatable way to find those problems before users lose confidence in the report.
The review follows the report from source to visual, then measures performance and access. Record the evidence as you go so another person can reproduce each check.
1. Set a baseline
Write down the report's purpose, audience, refresh schedule, metric definitions, and expected totals. Capture the current model size, refresh duration, page count, and several trusted results. Record the date range and filters used for every comparison. This baseline lets you distinguish a real improvement from a change in the test conditions.
2. Trace discrepancies from the visual back to the source
Pick a few important figures: a headline total, a distinct count, and a ratio. Recalculate each against an authoritative source for exactly the same period and inclusion rules. In Power BI Desktop, use Show as a table to inspect the rows behind a visual; clear or record page, report, and visual filters before comparing.
If a figure differs, check date boundaries, currency and units, blanks, duplicate keys, relationship cardinality, and filter direction. Compare row counts and distinct keys after each transformation. A reconciliation should explain the difference rather than hide it with an unexplained adjustment.
3. Validate the DAX measures users rely on
List the measures that drive the main pages and note their dependencies. Test each critical measure at detail, subtotal, and grand-total levels, with a single date and a multi-date selection, and with relevant slicers changed. Include blank categories and zero denominators in the test cases.
Review how CALCULATE, context transition, ALL or REMOVEFILTERS, inactive relationships, and time-intelligence functions affect filter context. A measure that returns the right grand total can still be wrong for each subgroup. Compare results with a simple control calculation where possible. Use Performance Analyzer to identify expensive visuals, then inspect their queries and server timings in DAX Studio.
4. Review Power Query and refresh
Inspect each query for unused columns, unnecessary rows, repeated transformations, hard-coded paths, implicit type changes, and row-by-row custom functions. Confirm query folding is preserved for supported sources; a later step can move a large workload from the source into the local mashup engine. Verify the expected grain and key uniqueness before data enters the model.
Run a refresh and record its duration, warnings, and failures. Check parameters, credentials, gateway mappings, and privacy settings in the target environment. A successful refresh is not enough if it loaded duplicate or incomplete rows.
5. Profile model size and report performance
Use Performance Analyzer to find slow visuals. Copy a slow visual's DAX query into DAX Studio and inspect Server Timings and the query plan to locate expensive scans. Use VertiPaq Analyzer, available through DAX Studio, to review table and column sizes, cardinality, and encoding.
High-cardinality text columns, unused fields, duplicate lookup tables, and unnecessarily detailed fact tables can inflate the model. Remove fields the report does not need, keep a clear star schema, and avoid storing duplicate derived values without a reason. Compare model size, refresh duration, and representative visual response times against the baseline after each change.
6. Test RLS and sharing permissions
List every role and the users or groups assigned to it. In Desktop, use View as to test each role and verify both that restricted rows disappear and permitted totals remain correct. For dynamic RLS, validate the identity expression against the actual user field and the model relationships.
Then review the published semantic model's permissions, workspace roles, app audience, direct shares, and Build permission. Workspace Admin, Member, and Contributor roles have broader capabilities than Viewer access, so confirm that editing access matches the intended boundary. Check data-source credentials and gateway ownership, and consider whether exports or connected experiences expose sensitive data.
7. Report findings and retest
For each finding, record its impact, affected page or measure, test performed, observed result, and recommended fix. Separate correctness and access problems from performance opportunities. After changes, repeat the same reconciliations, role tests, refresh, and visual timing checks used in the baseline.
Power BI health-check checklist
- Reconcile key totals, counts, and ratios against a trusted source with recorded filters.
- Test critical measures at detail, subtotal, and grand-total levels.
- Check query folding, data grain, key uniqueness, credentials, and refresh warnings.
- Profile slow visuals with Performance Analyzer and DAX Studio.
- Inspect model size and column cardinality with VertiPaq Analyzer.
- Test every RLS role and review workspace, app, and semantic-model permissions.
- Retest the baseline and preserve evidence for each finding.
A useful health check leaves the team with reproducible evidence, clear priorities, and a report that users can trust. The goal is not simply to make the report open without errors; it is to verify that its numbers, performance, and access behave as intended.