Power Bi Performance Troubleshooting

Power BI performance troubleshooting

Turn reported Power BI symptoms and available metrics into a scoped diagnosis, ranked root causes, concrete fixes, and before/after validation evidence.

When to invoke

• "Troubleshoot this slow Power BI report."
• "Why is this Power BI page taking more than 10 seconds to load?"
• "Diagnose DAX and model performance bottlenecks."
• "Find why our refresh or DirectQuery queries are timing out."
• "Analyze Fabric capacity, gateway, or Premium performance pressure."

Source evidence

Use the symptoms, affected reports/models, current performance metrics, environment and configuration details, previous troubleshooting attempts, business requirements, and constraints. If the user has no metrics, collect a baseline first rather than guessing.

Targets and symptoms

Use Report/model as the shorthand label when the evidence spans both artifacts, and call out slow-loading pages separately from slow interactions.

Procedure

1. Classify the issue: model loading/refresh performance, report page loading performance, visual interaction responsiveness, query execution speed, capacity resource constraints, or data source connectivity issues.
2. Scope the blast radius: all users vs. specific users, specific times vs. consistently, specific reports vs. all reports, certain data filters vs. all scenarios.
3. Collect the baseline: page load times, visual interaction response, query execution times, model refresh duration, memory and CPU utilization, and concurrent user load.
4. Diagnose from the closest layer to the symptom: report visuals, DAX, model architecture, storage mode, data source, gateway, network, then capacity.
5. Apply the lowest-risk fixes first, measure again, and escalate to advanced model redesign, aggregation, or infrastructure scaling only when evidence supports it.
6. Document root cause, changes, before/after metrics, validation, monitoring, and follow-up recommendations.

For by-step reproduction notes, list the exact interactions that cause the slowdown before proposing fixes.

Diagnostic criteria

Model performance

• Model size and complexity, relationship design and cardinality, and storage mode configuration (Import, DirectQuery, Composite) are reviewed.
• Legacy shorthand Import/DirectQuery/Composite is expanded into specific storage-mode evidence.
• Data types, compression efficiency, calculated columns vs. measures, and Date table implementation are checked.
• Common issues are flagged: unnecessary columns/rows, many-to-many relationships, bidirectional filters, high-cardinality text columns, excessive calculated columns, missing or improper Date tables, and poor data type selections.

DAX performance

• Measures avoid repeated calculations by using VAR and RETURN where values are reused.
• DIVIDE is used for safe division and error handling instead of manual fragile division.
• Context transition overhead, iterator function optimization, filter context complexity, nested CALCULATE, inefficient time intelligence, and FILTER() used as a filter argument are reviewed.

Sales Growth =
VAR CurrentMonth = [Total Sales]
VAR PreviousMonth = CALCULATE([Total Sales], PREVIOUSMONTH('Date'[Date]))
RETURN
    DIVIDE(CurrentMonth - PreviousMonth, PreviousMonth)

Report design

• Pages target 6-8 visuals maximum unless evidence shows acceptable performance.
• Drill-through, bookmarks, default filters, slicer design, cross-filtering configuration, visual interactions, custom visuals, and mobile layout are reviewed.
• High-cardinality slicers and resource competition from too many visuals are treated as likely bottlenecks.

Infrastructure and capacity

• Capacity utilization, query volume, workload distribution, network bandwidth, data source performance, gateway configuration, concurrent user patterns, and geographic distribution are reviewed.
• Fabric Capacity Metrics App or Premium Capacity Monitoring evidence is used for CPU, memory, refresh, user activity, and query queuing trends.
• Gateway optimization considers dedicated gateway clusters, load balancing configuration, connection optimization, and performance monitoring.

Tools and techniques

Fix patterns

Troubleshooting workflows

Monitoring cadence

Output template

## Power BI performance troubleshooting report — <report/model>

**Status:** diagnosed | partially diagnosed | blocked
**Symptom:** <page load, visual interaction, query, refresh, capacity, gateway, or source issue>
**Scope:** <users/reports/times/filters affected>

### Baseline
| Metric | Current | Target | Evidence |
| --- | --- | --- | --- |
| Page load time | <value> | <10 seconds | <Performance Analyzer/export/user timing> |
| Visual response | <value> | <3 seconds | <evidence> |
| Query execution | <value> | <30 seconds | <DAX Studio/source evidence> |
| Capacity CPU/memory | <value> | <threshold> | <Fabric/Premium evidence> |

### Findings
| # | Layer | Root cause | Evidence | Fix | Expected impact |
| --- | --- | --- | --- | --- | --- |
| 1 | DAX | <issue> | <measure/timing> | <change> | <impact> |
| 2 | Model | <issue> | <metadata/timing> | <change> | <impact> |

### Resolution documentation
- **Changes implemented:** <optimization changes>
- **Before/after metrics:** <measured improvement>
- **Validation and testing completed:** <checks>
- **Monitoring setup:** <ongoing health checks>
- **Follow-up recommendations:** <next steps>

Quality gate

• Issue classification, scope assessment, and baseline metrics are stated before root cause claims.
• Performance Analyzer, DAX Studio, Fabric Capacity Metrics App, Premium Capacity Monitoring, or equivalent evidence is cited when available.
• Findings distinguish model, DAX, report, data source, gateway, network, and capacity causes.
• Recommendations include immediate fixes and escalation criteria for advanced solutions.
• Before/after performance metrics and monitoring follow-up are documented.
• The output follows ## Output template exactly.