Back to Blog

Power BI Performance Audit - The Checklist We Use Before Scaling Any Tenant

May 19, 2026•12 min read•Michael Ridland

There is a moment in every Power BI rollout where the wheels start coming off. You added a few more reports. The Finance team joined. Someone connected a new SQL source. And suddenly the executives are complaining that the dashboard they used to love now takes 30 seconds to render and the morning refresh is failing twice a week.

We get called in at exactly this point. The fix is rarely a single thing. It is usually four or five smaller problems compounding, and once you find them, the path forward is obvious. The harder question is how to spot the problems before they spiral, which is what a proper performance audit is for.

This is the audit checklist we run for Australian clients who are about to do something significant with their Power BI environment - whether that is scaling users, ingesting more data, moving to Fabric, or migrating off Excel-based reporting. It is the same checklist we run internally before recommending any scale-up to a client.

When You Actually Need an Audit

Not every Power BI environment needs an audit. If you have under 50 users, a few dozen reports, and refreshes that complete in under 30 minutes, you probably do not have a problem worth paying to fix.

Where it makes sense to invest in an audit:

  • You are about to roll out to a new department or business unit and double the user base
  • You are seeing report load times creep past 10 seconds and getting complaints
  • Your scheduled refreshes are taking 50 percent longer than they did six months ago
  • You are evaluating Fabric capacity and need to know what your actual workload looks like
  • You are about to add a major new data source and want to know if the existing model can handle it
  • You are migrating from Pro to Premium or Premium to Fabric capacity and want to right-size
  • You have inherited a Power BI environment from a previous team or consultant

For most of our clients, an audit costs $8,000 to $20,000 AUD depending on the size of the environment. A typical engagement is a week of investigation followed by a written report and a one-day workshop to walk the findings through with the client team. For Premium or Fabric environments at the larger end, it can run to $30,000 to $50,000 AUD if there are dozens of workspaces and hundreds of datasets to assess.

The Eight Areas We Audit

A real audit is not just running Performance Analyzer on the slowest report. It looks at the whole environment because performance problems are usually a chain reaction, not a single cause.

1. Capacity and Licensing

Start here. Get the actual licensing in writing. We see organisations paying for Premium capacity they do not need, and others scraping along on Pro when their workload genuinely requires Premium.

For Pro environments, count active users (people who have opened a report in the last 30 days), not provisioned licences. We have audited tenants where the client thought they had 200 Pro users and the actual active count was 47. That changes the licensing maths considerably.

For Premium and Fabric environments, pull the capacity metrics from the Microsoft Fabric Capacity Metrics App. Look at CU consumption over 28 days, the peaks, and how often you are exceeding 80 percent utilisation. If you are regularly at or above 90 percent during business hours, you have a capacity problem that no amount of report optimisation will fix.

Australian pricing as of 2026: Pro is around $20 AUD per user per month. Premium per User is around $36 AUD per user per month. F-SKU Fabric capacities run from around $400 per month for an F2 up to enterprise-tier capacities in the tens of thousands per month. The right answer depends on user count, workload, and whether you need Fabric workloads beyond Power BI.

2. Data Model Design

This is where the biggest performance gains hide. Most slow Power BI reports are not slow because of visuals. They are slow because the underlying model is doing too much work at query time.

What we look for:

  • Star schema or spaghetti. If you see bidirectional relationships, many-to-many joins that should not exist, and fact tables joined directly to other fact tables, you have a remediation project. Star schema is not dogma, it is what the VertiPaq engine is optimised for.
  • Column cardinality. High-cardinality text columns (full names, free-text descriptions, GUIDs) destroy compression. Often these can be split, hashed, or moved out of the model entirely.
  • Calculated columns vs measures. Calculated columns that should be measures inflate model size. Measures that should be calculated columns kill query performance. We see both regularly.
  • Auto date/time tables. Power BI's automatic date tables generate hidden tables for every date column in the model. Turn this off and use a proper Date dimension instead. We have seen 30 percent file size reductions from this alone.
  • Unused columns. Most semantic models have 20 to 40 percent of columns that no report or measure references. Remove them.

We run Tabular Editor's Best Practice Analyzer against every semantic model in the audit and document the top violations by impact. The BPA is free, takes 10 minutes to install, and finds the issues that matter.

3. DAX Quality

DAX written by analysts learning as they go has a particular smell. Iterators inside iterators. Heavy use of FILTER where CALCULATE would do. Repeated context transitions. Variables that are not actually being reused.

For each top 10 slowest measure in the environment, we run DAX Studio's Server Timings against representative queries and capture the storage engine vs formula engine breakdown. If formula engine time dominates, the DAX needs rewriting. If storage engine time dominates, the model is the problem.

A common pattern in audits is one or two measures used in dozens of reports that are each individually expensive. Optimising those two measures can drop average report load time by 40 percent across the tenant. The 80/20 rule applies hard here.

4. Refresh Performance

Slow refreshes are the second most common complaint after slow reports. The audit checks:

  • How long each dataset takes to refresh, broken down by table
  • Which tables are full refresh vs incremental refresh
  • Whether incremental refresh is configured correctly (the most common configuration error is too much partition retention or refresh windows that overlap)
  • Whether the source system can handle the query load that Power BI generates
  • Whether gateway throughput is the bottleneck (for on-premises sources)
  • Whether dataflows or pipelines could move transformation work upstream of Power BI

The single highest-impact change we recommend in maybe 40 percent of audits is enabling incremental refresh on fact tables larger than 10 million rows. The difference between a four-hour full refresh and a 15-minute incremental refresh is night and day, and it costs nothing extra in licensing.

If your refreshes are pulling data from sources that should be in Microsoft Fabric or Data Factory, we usually flag this as a longer-term remediation. Power BI is a presentation layer, not a transformation engine.

5. Report Design

Visuals matter. A report with 25 visuals on a single page, three slicers each filtering five tables, and conditional formatting on every column will be slow no matter how good your model is.

The report-level checks:

  • Page-level visual count (more than 12 is a red flag)
  • Custom visuals vs native (custom visuals are usually slower and sometimes broken)
  • Slicer count and slicer types (drop-downs are faster than lists for high-cardinality fields)
  • Use of "Show items with no data" (turn off where possible, it changes query patterns)
  • Cross-filter and cross-highlight configuration (often misconfigured in ways that fire unnecessary queries)
  • Bookmark and selection navigation depth (overuse causes memory pressure)

Performance Analyzer in Power BI Desktop is the right tool for this. Capture the queries for each visual on each page, sort by total duration, and you have your remediation list.

6. Workspace and Tenant Governance

This is where audits get political. Most Power BI environments grow organically, which means by year three you have personal workspaces with production reports, duplicated semantic models across teams, datasets that nobody owns, and refresh credentials tied to ex-employees.

What we document:

  • Number of workspaces and their classification (development, test, production)
  • Datasets with no owner or with an owner who has left the organisation
  • Reports built on personal workspaces that should be in shared workspaces
  • Duplicated semantic models across workspaces (the "every team has its own copy of the same data" problem)
  • Sensitivity labelling and DLP configuration
  • Export and sharing permissions

For Australian clients, we also check that data residency is configured correctly for the relevant capacity, that Australia East or Australia Southeast is being used as appropriate, and that any datasets containing personal information are tagged for Australian Privacy Act compliance.

7. Gateway Configuration

For environments still pulling data from on-premises sources (which is most of them in Australia), the gateway is often where performance dies.

The audit checks:

  • Gateway cluster configuration (single node is a risk, two-node minimum for any real production use)
  • Gateway machine specs vs workload (we still see gateways running on a Windows VM with 4 GB of RAM trying to refresh 50 datasets)
  • Concurrent refresh limits and how they interact with peak refresh times
  • Network latency between gateway and data sources
  • Gateway logs for throttling, queue depth, and refresh failure patterns

A common finding is gateways that were sized for the original deployment and never resized as workload grew. Doubling the RAM and CPU on a gateway machine is a $1,500 AUD per year incremental cloud cost that can take 30 minutes off your refresh window. Easy win.

8. Usage and Adoption

The last area is one most audits skip, but it is essential for scaling decisions. The Usage Metrics dataset for each workspace tells you which reports are actually being opened, by how many users, and how often.

The findings here are usually uncomfortable:

  • 60 to 80 percent of reports in a typical tenant are opened by fewer than five people per month
  • 20 to 40 percent of reports have not been opened in the last 90 days
  • A small handful of reports account for the majority of all views

Before you scale, you should know which reports actually matter to the business. There is no point optimising a report that nobody uses, and there is every point on focusing your effort on the dashboards that the CFO opens every Monday morning.

Quick Self-Assessment

If you do not want to engage a consultant yet, here is a quick self-assessment you can run in an afternoon. Three or more "yes" answers suggests it is time for a proper audit.

  • At least one report takes longer than 15 seconds to load on first open
  • Refresh duration has grown by more than 25 percent in the last six months
  • You have datasets larger than 1 GB without incremental refresh configured
  • You have semantic models with bidirectional relationships
  • You are running on Premium or Fabric capacity at over 80 percent peak utilisation
  • You have not run Best Practice Analyzer against your main semantic models
  • More than 25 percent of your reports have not been opened in 90 days
  • You are about to add a new team of 50+ users to the environment
  • Your gateway is a single machine
  • You cannot say with certainty who owns each production dataset

What Happens After the Audit

The deliverable from a good audit is a prioritised remediation list, not a 200-page document that nobody reads.

We structure findings into three buckets:

  • Fix this week. Low effort, high impact items. Usually 5 to 15 of these. Examples: turning off auto date/time, fixing a broken incremental refresh config, adding a gateway node.
  • Fix this quarter. Medium effort items that need scheduling. Examples: rewriting the top five slow measures, redesigning the customer dimension, consolidating duplicated datasets.
  • Fix this year. Architecture changes. Examples: moving transformation logic upstream into Microsoft Fabric or Data Factory, splitting the monolithic semantic model into business-area-specific models, migrating from Pro to Premium.

The first bucket is usually doable internally if you have a capable Power BI developer on staff. The second and third buckets are where most of our follow-on consulting work happens.

When to Engage a Consultant

You do not need a consultant for every Power BI audit. If you have a senior Power BI developer with 5+ years of experience and bandwidth to spend a week on it, give them the checklist above and let them run it.

Where external help pays off:

  • The internal team built the environment and cannot see its own blind spots
  • You need an independent voice for a difficult conversation with executives about Fabric or capacity costs
  • The environment has grown beyond what any one internal person understands
  • You are about to spend a large amount on Fabric capacity and want validation before you commit
  • You need remediation done quickly and do not have internal bandwidth

Team 400 runs Power BI audits for Australian organisations across most industries. We work with clients across Sydney, Brisbane, Melbourne, and from our base on the Sunshine Coast. The full Power BI consulting offering is at /power-bi-consultants.

If you are weighing up an audit or want a second opinion on whether one is worth doing for your environment, the quickest path is to send us a note via the contact page. We can usually tell you in a 30-minute call whether a paid audit will pay back, and if not, what to focus on internally instead. There is also useful context in our writing on data culture in Power BI if you are thinking about the broader analytics maturity question.