Power BI Monitoring and Alerting Setup Guide
Implement comprehensive monitoring and alerting for Power BI with Premium Metrics, Capacity Metrics, and automated alerts for performance degradation.
Proactive monitoring and alerting transforms Power BI administration from reactive firefighting into strategic platform management. Without monitoring, you discover problems when executives complain that their dashboard is broken — which is the worst possible time. With a proper monitoring stack, you detect failing refreshes, degrading query performance, capacity overload, and security anomalies before users notice anything. Our managed analytics team operates monitoring infrastructure for organizations with 500 to 50,000 Power BI users, maintaining 99.9%+ platform uptime through automated detection and response.
This guide covers the complete Power BI monitoring architecture including data collection, KPI dashboards, alerting rules, incident response, and integration with enterprise monitoring platforms.
Monitoring Architecture Overview
A production monitoring system for Power BI has four layers: data collection, storage, visualization, and alerting.
Architecture components:
``` Data Collection Layer: Power BI Activity Log -> Azure Event Hub -> Log Analytics Workspace Power BI REST API -> Scheduled Function App -> Log Analytics Workspace Fabric Capacity Metrics -> Direct -> Capacity Metrics App Gateway Performance -> Log Analytics -> Custom Dashboard
Storage Layer: Azure Log Analytics Workspace (90-365 day retention) Azure SQL Database (long-term analytics, 2+ year retention)
Visualization Layer: Power BI Monitoring Dashboard (the meta-dashboard) Fabric Capacity Metrics App Azure Monitor Dashboards
Alerting Layer: Azure Monitor Alert Rules -> Action Groups -> Email/Teams/PagerDuty Power Automate Flows -> Custom notification logic Microsoft Sentinel (for security-focused monitoring) ```
Data Collection: What to Monitor
1. Activity Log
The Power BI Activity Log captures every user and system action in the tenant. It is the foundation of all monitoring.
Key events to track:
| Event Category | Specific Events | Why It Matters |
|---|---|---|
| Refresh | RefreshDataset, RefreshDatasetFailed | Detect broken refreshes before users see stale data |
| Export | ExportReport, ExportToPDF, ExportToExcel | Data exfiltration risk, governance compliance |
| Sharing | ShareReport, ShareDashboard | Track content distribution, detect over-sharing |
| Access | ViewReport, ViewDashboard | Usage analytics, identify unused content |
| Admin | UpdateTenantSettings, UpdateGateway | Configuration change detection |
| Security | AddGroupMembers, DeleteGroup | Access control changes |
| Capacity | CapacityStateChange, ThrottlingEvent | Performance and cost monitoring |
Activity Log extraction methods:
| Method | Latency | Retention | Best For |
|---|---|---|---|
| Get-PowerBIActivityEvent (PowerShell) | 30 minutes | Must export daily (logs available for 30 days) | Scheduled extraction to Log Analytics |
| Power BI REST API /activityevents | 30 minutes | Same as above | Custom applications |
| Microsoft 365 Management API | Minutes | Configurable | Real-time streaming |
| Azure Event Hub streaming (preview) | Near real-time | Configurable | Enterprise-grade real-time monitoring |
Recommended approach: Stream to Azure Event Hub for real-time alerting. Also run daily PowerShell extraction to Log Analytics for historical analysis and compliance retention.
2. REST API Metadata Collection
Schedule regular API calls to collect platform inventory and health metrics.
Metadata to collect hourly/daily:
``` Workspaces: - List all workspaces (GET /groups) - Workspace membership and roles - Last activity timestamp per workspace
Datasets: - All datasets across all workspaces (Scanner API) - Refresh schedules and last refresh status - Data source configurations - RLS role definitions
Reports: - All reports and their workspace assignments - Report usage metrics (views, unique users) - Report page count and visual count
Gateways: - Gateway cluster health status - Data source configurations per gateway - Queue depth and active connections
Capacity: - Assigned workspaces per capacity - Utilization metrics via Capacity Metrics API ```
3. Gateway Monitoring
On-premises data gateways are a common failure point. Dedicate specific monitoring attention to them.
Gateway health metrics:
| Metric | Collection Method | Alert Threshold |
|---|---|---|
| Gateway service status | Windows Service Monitor | Service not running |
| Query duration P90 | Gateway logs in Log Analytics | > 30 seconds |
| Concurrent queries | Gateway performance counters | > 80% of max concurrent |
| Memory utilization | Performance counters | > 85% |
| Failed queries | Activity Log (RefreshDatasetFailed) | Any failure |
| Disk space on gateway host | OS monitoring | < 20% free |
| Certificate expiration | Custom check | < 30 days |
4. Capacity Metrics
For Fabric capacity or Power BI Premium, capacity monitoring prevents throttling and optimizes cost.
**Use the Fabric Capacity Metrics app for:** - CU utilization trends (hourly, daily, weekly) - Throttling event frequency and duration - Top consumers by workspace and item type - Background vs. interactive workload distribution - Overload prediction based on trend analysis
Monitoring Dashboard Design
Build a dedicated Power BI monitoring dashboard — the "meta-dashboard" that monitors all other dashboards.
Dashboard Sections
Section 1: Platform Health Summary
| KPI | Target | Visual |
|---|---|---|
| Dataset refresh success rate | > 99% | KPI card with trend |
| Average report load time | < 3 seconds | Gauge |
| Active users (last 7 days) | Track trend | Line chart |
| Capacity utilization | 50-80% | Gauge with warning zones |
| Open incidents | 0 | Count card |
Section 2: Refresh Monitoring
- List of all scheduled refreshes with status (success/failed/in progress)
- Refresh duration trends by dataset
- Failed refresh detail with error messages
- Refresh queue depth and wait times
- Longest running refreshes (optimization candidates)
Section 3: Usage Analytics
- Daily/weekly/monthly active users
- Most-viewed reports (top 20)
- Least-viewed reports (candidates for retirement)
- Peak usage hours (for capacity planning)
- User adoption by department
Section 4: Security and Governance
- Data export events (volume and frequency)
- External sharing events
- RLS configuration coverage (% of sensitive datasets with RLS)
- Admin setting changes
- Service principal activity
Section 5: Gateway Performance
- Query duration by gateway cluster
- Queue depth trends
- Connection failure rates
- Gateway host resource utilization
Alerting Rules
Effective alerting requires careful threshold setting. Too many alerts create alert fatigue. Too few miss critical issues.
Critical Alerts (Immediate Response Required)
| Alert | Condition | Response Time | Notification |
|---|---|---|---|
| Production dataset refresh failed | RefreshDatasetFailed for certified datasets | 15 minutes | Teams + Email + PagerDuty |
| Capacity throttling sustained | CU > 100% for > 30 minutes | 30 minutes | Teams + Email |
| Gateway service down | Service status = stopped | 5 minutes | PagerDuty |
| Unauthorized admin action | TenantSettings changed outside change window | 15 minutes | Email + Security team |
| Mass data export | > 50 export events from single user in 1 hour | 30 minutes | Security team |
Warning Alerts (Business Hours Response)
| Alert | Condition | Response Time | Notification |
|---|---|---|---|
| Non-production refresh failed | Any non-certified dataset refresh failure | 4 hours | |
| Capacity utilization high | CU > 80% sustained for > 2 hours | 4 hours | Teams |
| Report performance degraded | P90 load time > 5 seconds for any report | 1 business day | |
| Workspace approaching size limit | Dataset > 80% of capacity dataset size limit | 1 business day | |
| Gateway certificate expiring | < 30 days until expiration | 1 business day |
Informational Alerts (Weekly Review)
| Alert | Condition | Review Cadence |
|---|---|---|
| Unused reports | No views in 30 days | Weekly |
| Orphaned workspaces | No active users in 60 days | Weekly |
| Refresh duration increase | > 50% increase in refresh time | Weekly |
| New workspaces created | Any new workspace creation | Weekly |
Incident Response Playbooks
Monitoring is useless without defined response procedures.
Playbook: Dataset Refresh Failure
``` 1. Check error message in Activity Log 2. Common causes and fixes: - Credential expired -> Update data source credentials - Source unavailable -> Check source system status - Timeout -> Optimize query or increase timeout - Memory limit -> Optimize model, remove unused columns - Gateway error -> Check gateway health, restart if needed 3. Trigger manual refresh after fix 4. Verify success 5. Document in incident log ```
Playbook: Capacity Throttling
``` 1. Check Capacity Metrics app for top consumers 2. Identify spike cause: - Unscheduled heavy refresh -> Reschedule to off-peak - Query storm from popular report -> Enable query caching - Spark job overconsumption -> Adjust resource limits 3. Short-term: Kill or pause non-critical workloads 4. Long-term: Implement scheduling optimization per our cost management guide 5. Evaluate capacity right-sizing ```
Playbook: Gateway Down
``` 1. Verify gateway service status on host machine 2. Check Windows Event Log for crash details 3. Restart gateway service 4. If restart fails: - Check disk space - Check memory - Check network connectivity to Power BI service - Check certificate validity 5. Verify queries flowing after recovery 6. Review gateway logs for root cause ```
Integration with Enterprise Monitoring
Microsoft Sentinel Integration
For organizations using Microsoft Sentinel for security operations: - Forward Power BI Activity Log to Sentinel workspace - Create detection rules for suspicious patterns (mass export, unusual admin activity, off-hours access from unknown IPs) - Correlate Power BI events with Azure AD sign-in logs
ServiceNow Integration
- Create ServiceNow incidents automatically from critical alerts
- Link Power BI monitoring tickets to gateway or capacity CIs
- Track MTTR (Mean Time to Resolution) for Power BI incidents
Prometheus/Grafana Integration
For organizations using Prometheus: - Export Power BI metrics via custom exporter (Function App that scrapes REST API and exposes /metrics endpoint) - Grafana dashboards alongside infrastructure monitoring - Unified alerting through AlertManager
Automation Opportunities
Use Power Automate and Azure Functions to automate common monitoring responses:
| Trigger | Automated Response |
|---|---|
| Dataset refresh failed | Retry refresh once, alert if second failure |
| Capacity > 90% for 15 min | Pause non-critical background operations |
| New workspace created | Apply standard governance tags and policies |
| Report unused for 60 days | Send notification to workspace admin for cleanup review |
| Gateway queue depth > threshold | Scale gateway cluster by starting standby node |
Frequently Asked Questions
How long should I retain monitoring data? Retain Activity Log data for at least 1 year for compliance. Retain capacity metrics for 6 months for trend analysis. Retain gateway logs for 90 days for troubleshooting. Adjust based on your organization's compliance requirements (HIPAA, SOX, etc.).
What is the cost of the monitoring infrastructure? Azure Log Analytics costs approximately $2.76/GB ingested. A typical enterprise Power BI tenant generates 1-5 GB/month of monitoring data. Total monitoring infrastructure cost (Log Analytics + Function Apps + Storage) is typically $50-200/month — negligible compared to the cost of undetected outages.
Should I monitor Power BI Pro tenants or only Premium/Fabric? Monitor all tenants. The Activity Log and REST API work with Pro. Capacity-specific monitoring (CU utilization, throttling) only applies to Premium and Fabric.
How do I get started with minimal effort? Start with three things: (1) Schedule daily Activity Log extraction to Log Analytics, (2) Configure email alerts for certified dataset refresh failures, (3) Install the Fabric Capacity Metrics app. This takes 2-4 hours and covers the most critical monitoring needs. Expand from there based on your incident patterns.
Next Steps
Monitoring is a foundational capability that enables all other Power BI operations — governance, optimization, security, and user support. Our managed analytics team provides 24/7 Power BI platform monitoring with defined SLAs, automated incident response, and monthly health reporting. Contact us to discuss monitoring implementation or managed monitoring services.
**Related resources:** - Power BI Governance Framework - Fabric Capacity Metrics - Fabric Cost Management - Power BI Security Best Practices
Enterprise Implementation Best Practices
Rolling out Power BI monitoring at enterprise scale requires a structured approach that accounts for organizational complexity, regulatory requirements, and operational maturity. Having implemented monitoring architectures for organizations ranging from 500 to 50,000 Power BI users, these are the practices that consistently determine success or failure.
- Start with a monitoring charter. Define who owns monitoring (Platform Admin, CoE, IT Ops), what SLAs monitoring must support (99.9% uptime, 15-minute incident response), and how monitoring integrates with existing ITSM workflows. Without a charter, monitoring becomes an unfunded mandate that atrophies within months.
- Implement tiered alerting from day one. Critical alerts go to PagerDuty with immediate escalation. Warning alerts go to Teams channels during business hours. Informational alerts feed weekly digest reports. Flat alerting (everything to email) guarantees alert fatigue and missed incidents within the first month.
- Automate Activity Log extraction before anything else. The Activity Log is the foundation for security monitoring, usage analytics, governance compliance, and troubleshooting. Schedule daily PowerShell extraction to Azure Log Analytics and configure 365-day retention. This single automation covers 60% of monitoring use cases.
- Build the meta-dashboard iteratively. Start with refresh monitoring and capacity utilization — the two highest-impact sections. Add usage analytics in month two, security monitoring in month three, and gateway performance in month four. Trying to build all five sections simultaneously delays the entire project.
- Integrate with enterprise incident management. Connect critical alerts to ServiceNow, Jira Service Management, or your organization's ticketing system. Standalone monitoring that does not create trackable incidents will be ignored during production outages when the ticketing system is the source of truth.
- Test alerting rules quarterly. Simulate failure scenarios — kill a gateway service, trigger a dataset refresh failure, push capacity above threshold — and verify that the correct alerts fire, reach the right teams, and generate appropriate tickets. Untested alerting is unreliable alerting.
- **Document runbooks for every critical alert.** Each alert should link to a specific playbook in your knowledge base. When an on-call engineer receives a 2 AM capacity throttling alert, they should not have to figure out the response in real time. Invest in governance framework documentation that includes operational runbooks.
- Establish baseline metrics before setting thresholds. Run monitoring in observation mode for 2-4 weeks to establish normal patterns for refresh duration, query performance, and capacity utilization. Setting thresholds based on assumptions rather than baselines produces either constant false positives or missed real incidents.
Measuring Success and ROI
Monitoring investments require quantified business justification. Track these specific metrics to demonstrate value to executive stakeholders and secure ongoing budget for platform operations.
Operational metrics that prove monitoring ROI: - Mean Time to Detection (MTTD): Before monitoring, incident detection averaged 2-4 hours (waiting for user complaints). With proper monitoring, MTTD drops to under 15 minutes — a 90% reduction that translates directly to reduced business impact per incident. - Mean Time to Resolution (MTTR): Automated diagnostics and runbook integration typically reduce MTTR by 40-60%. For a 5,000-user deployment experiencing 2-3 incidents per week, this saves 15-25 hours of engineering time monthly. - Refresh success rate: Track the percentage of scheduled refreshes that complete successfully. Enterprise targets should exceed 99%. Each failed refresh represents stale data reaching decision-makers — quantify the business cost of decisions made on outdated data. - Capacity utilization efficiency: Monitoring enables right-sizing capacity, typically saving 15-25% on Premium/Fabric licensing costs. For an organization spending $100K annually on capacity, this represents $15-25K in direct savings. - User satisfaction scores: Correlate monitoring deployment with quarterly user satisfaction surveys. Organizations with proactive monitoring consistently score 20-30% higher on platform reliability satisfaction compared to reactive-only environments.
Report these metrics monthly to executive sponsors using a dedicated Power BI monitoring dashboard that tracks trends over time and highlights the correlation between monitoring maturity and platform reliability.
For expert help implementing Power BI monitoring and alerting in your enterprise, contact our consulting team for a free assessment.``` Data Collection Layer: Power BI Activity Log -> Azure Event Hub -> Log Analytics Workspace Power BI REST API -> Scheduled Function App -> Log Analytics Workspace Fabric Capacity Metrics -> Direct -> Capacity Metrics App Gateway Performance -> Log Analytics -> Custom Dashboard
Storage Layer: Azure Log Analytics Workspace (90-365 day retention) Azure SQL Database (long-term analytics, 2+ year retention)
Visualization Layer: Power BI Monitoring Dashboard (the meta-dashboard) Fabric Capacity Metrics App Azure Monitor Dashboards
Alerting Layer: Azure Monitor Alert Rules -> Action Groups -> Email/Teams/PagerDuty Power Automate Flows -> Custom notification logic Microsoft Sentinel (for security-focused monitoring) ```
Data Collection: What to Monitor
1. Activity Log
The Power BI Activity Log captures every user and system action in the tenant. It is the foundation of all monitoring.
Key events to track:
| Event Category | Specific Events | Why It Matters |
|---|---|---|
| Refresh | RefreshDataset, RefreshDatasetFailed | Detect broken refreshes before users see stale data |
| Export | ExportReport, ExportToPDF, ExportToExcel | Data exfiltration risk, governance compliance |
| Sharing | ShareReport, ShareDashboard | Track content distribution, detect over-sharing |
| Access | ViewReport, ViewDashboard | Usage analytics, identify unused content |
| Admin | UpdateTenantSettings, UpdateGateway | Configuration change detection |
| Security | AddGroupMembers, DeleteGroup | Access control changes |
| Capacity | CapacityStateChange, ThrottlingEvent | Performance and cost monitoring |
Activity Log extraction methods:
| Method | Latency | Retention | Best For |
|---|---|---|---|
| Get-PowerBIActivityEvent (PowerShell) | 30 minutes | Must export daily (logs available for 30 days) | Scheduled extraction to Log Analytics |
| Power BI REST API /activityevents | 30 minutes | Same as above | Custom applications |
| Microsoft 365 Management API | Minutes | Configurable | Real-time streaming |
| Azure Event Hub streaming (preview) | Near real-time | Configurable | Enterprise-grade real-time monitoring |
Recommended approach: Stream to Azure Event Hub for real-time alerting. Also run daily PowerShell extraction to Log Analytics for historical analysis and compliance retention.
2. REST API Metadata Collection
Schedule regular API calls to collect platform inventory and health metrics.
Metadata to collect hourly/daily:
``` Workspaces: - List all workspaces (GET /groups) - Workspace membership and roles - Last activity timestamp per workspace
Datasets: - All datasets across all workspaces (Scanner API) - Refresh schedules and last refresh status - Data source configurations - RLS role definitions
Reports: - All reports and their workspace assignments - Report usage metrics (views, unique users) - Report page count and visual count
Gateways: - Gateway cluster health status - Data source configurations per gateway - Queue depth and active connections
Capacity: - Assigned workspaces per capacity - Utilization metrics via Capacity Metrics API ```
3. Gateway Monitoring
On-premises data gateways are a common failure point. Dedicate specific monitoring attention to them.
Gateway health metrics:
| Metric | Collection Method | Alert Threshold |
|---|---|---|
| Gateway service status | Windows Service Monitor | Service not running |
| Query duration P90 | Gateway logs in Log Analytics | > 30 seconds |
| Concurrent queries | Gateway performance counters | > 80% of max concurrent |
| Memory utilization | Performance counters | > 85% |
| Failed queries | Activity Log (RefreshDatasetFailed) | Any failure |
| Disk space on gateway host | OS monitoring | < 20% free |
| Certificate expiration | Custom check | < 30 days |
4. Capacity Metrics
For Fabric capacity or Power BI Premium, capacity monitoring prevents throttling and optimizes cost.
**Use the Fabric Capacity Metrics app for:** - CU utilization trends (hourly, daily, weekly) - Throttling event frequency and duration - Top consumers by workspace and item type - Background vs. interactive workload distribution - Overload prediction based on trend analysis
Monitoring Dashboard Design
Build a dedicated Power BI monitoring dashboard — the "meta-dashboard" that monitors all other dashboards.
Dashboard Sections
Section 1: Platform Health Summary
| KPI | Target | Visual |
|---|---|---|
| Dataset refresh success rate | > 99% | KPI card with trend |
| Average report load time | < 3 seconds | Gauge |
| Active users (last 7 days) | Track trend | Line chart |
| Capacity utilization | 50-80% | Gauge with warning zones |
| Open incidents | 0 | Count card |
Section 2: Refresh Monitoring
- List of all scheduled refreshes with status (success/failed/in progress)
- Refresh duration trends by dataset
- Failed refresh detail with error messages
- Refresh queue depth and wait times
- Longest running refreshes (optimization candidates)
Section 3: Usage Analytics
- Daily/weekly/monthly active users
- Most-viewed reports (top 20)
- Least-viewed reports (candidates for retirement)
- Peak usage hours (for capacity planning)
- User adoption by department
Section 4: Security and Governance
- Data export events (volume and frequency)
- External sharing events
- RLS configuration coverage (% of sensitive datasets with RLS)
- Admin setting changes
- Service principal activity
Section 5: Gateway Performance
- Query duration by gateway cluster
- Queue depth trends
- Connection failure rates
- Gateway host resource utilization
Alerting Rules
Effective alerting requires careful threshold setting. Too many alerts create alert fatigue. Too few miss critical issues.
Critical Alerts (Immediate Response Required)
| Alert | Condition | Response Time | Notification |
|---|---|---|---|
| Production dataset refresh failed | RefreshDatasetFailed for certified datasets | 15 minutes | Teams + Email + PagerDuty |
| Capacity throttling sustained | CU > 100% for > 30 minutes | 30 minutes | Teams + Email |
| Gateway service down | Service status = stopped | 5 minutes | PagerDuty |
| Unauthorized admin action | TenantSettings changed outside change window | 15 minutes | Email + Security team |
| Mass data export | > 50 export events from single user in 1 hour | 30 minutes | Security team |
Warning Alerts (Business Hours Response)
| Alert | Condition | Response Time | Notification |
|---|---|---|---|
| Non-production refresh failed | Any non-certified dataset refresh failure | 4 hours | |
| Capacity utilization high | CU > 80% sustained for > 2 hours | 4 hours | Teams |
| Report performance degraded | P90 load time > 5 seconds for any report | 1 business day | |
| Workspace approaching size limit | Dataset > 80% of capacity dataset size limit | 1 business day | |
| Gateway certificate expiring | < 30 days until expiration | 1 business day |
Informational Alerts (Weekly Review)
| Alert | Condition | Review Cadence |
|---|---|---|
| Unused reports | No views in 30 days | Weekly |
| Orphaned workspaces | No active users in 60 days | Weekly |
| Refresh duration increase | > 50% increase in refresh time | Weekly |
| New workspaces created | Any new workspace creation | Weekly |
Incident Response Playbooks
Monitoring is useless without defined response procedures.
Playbook: Dataset Refresh Failure
``` 1. Check error message in Activity Log 2. Common causes and fixes: - Credential expired -> Update data source credentials - Source unavailable -> Check source system status - Timeout -> Optimize query or increase timeout - Memory limit -> Optimize model, remove unused columns - Gateway error -> Check gateway health, restart if needed 3. Trigger manual refresh after fix 4. Verify success 5. Document in incident log ```
Playbook: Capacity Throttling
``` 1. Check Capacity Metrics app for top consumers 2. Identify spike cause: - Unscheduled heavy refresh -> Reschedule to off-peak - Query storm from popular report -> Enable query caching - Spark job overconsumption -> Adjust resource limits 3. Short-term: Kill or pause non-critical workloads 4. Long-term: Implement scheduling optimization per our cost management guide 5. Evaluate capacity right-sizing ```
Playbook: Gateway Down
``` 1. Verify gateway service status on host machine 2. Check Windows Event Log for crash details 3. Restart gateway service 4. If restart fails: - Check disk space - Check memory - Check network connectivity to Power BI service - Check certificate validity 5. Verify queries flowing after recovery 6. Review gateway logs for root cause ```
Integration with Enterprise Monitoring
Microsoft Sentinel Integration
For organizations using Microsoft Sentinel for security operations: - Forward Power BI Activity Log to Sentinel workspace - Create detection rules for suspicious patterns (mass export, unusual admin activity, off-hours access from unknown IPs) - Correlate Power BI events with Azure AD sign-in logs
ServiceNow Integration
- Create ServiceNow incidents automatically from critical alerts
- Link Power BI monitoring tickets to gateway or capacity CIs
- Track MTTR (Mean Time to Resolution) for Power BI incidents
Prometheus/Grafana Integration
For organizations using Prometheus: - Export Power BI metrics via custom exporter (Function App that scrapes REST API and exposes /metrics endpoint) - Grafana dashboards alongside infrastructure monitoring - Unified alerting through AlertManager
Automation Opportunities
Use Power Automate and Azure Functions to automate common monitoring responses:
| Trigger | Automated Response |
|---|---|
| Dataset refresh failed | Retry refresh once, alert if second failure |
| Capacity > 90% for 15 min | Pause non-critical background operations |
| New workspace created | Apply standard governance tags and policies |
| Report unused for 60 days | Send notification to workspace admin for cleanup review |
| Gateway queue depth > threshold | Scale gateway cluster by starting standby node |
Frequently Asked Questions
How long should I retain monitoring data? Retain Activity Log data for at least 1 year for compliance. Retain capacity metrics for 6 months for trend analysis. Retain gateway logs for 90 days for troubleshooting. Adjust based on your organization's compliance requirements (HIPAA, SOX, etc.).
What is the cost of the monitoring infrastructure? Azure Log Analytics costs approximately $2.76/GB ingested. A typical enterprise Power BI tenant generates 1-5 GB/month of monitoring data. Total monitoring infrastructure cost (Log Analytics + Function Apps + Storage) is typically $50-200/month — negligible compared to the cost of undetected outages.
Should I monitor Power BI Pro tenants or only Premium/Fabric? Monitor all tenants. The Activity Log and REST API work with Pro. Capacity-specific monitoring (CU utilization, throttling) only applies to Premium and Fabric.
How do I get started with minimal effort? Start with three things: (1) Schedule daily Activity Log extraction to Log Analytics, (2) Configure email alerts for certified dataset refresh failures, (3) Install the Fabric Capacity Metrics app. This takes 2-4 hours and covers the most critical monitoring needs. Expand from there based on your incident patterns.
Next Steps
Monitoring is a foundational capability that enables all other Power BI operations — governance, optimization, security, and user support. Our managed analytics team provides 24/7 Power BI platform monitoring with defined SLAs, automated incident response, and monthly health reporting. Contact us to discuss monitoring implementation or managed monitoring services.
**Related resources:** - Power BI Governance Framework - Fabric Capacity Metrics - Fabric Cost Management - Power BI Security Best Practices
Frequently Asked Questions
What metrics should I monitor in Power BI Premium or Fabric capacity?
Critical capacity metrics to monitor: (1) CPU utilization—alert if sustained above 80% for 10+ minutes, (2) Memory usage—alert if above 90%, (3) Query duration—alert if P95 latency exceeds baseline by 50%, (4) Refresh failure rate—alert if above 5%, (5) Throttling events—alert on any capacity throttling, (6) Active queries—alert if queue depth exceeds capacity limits. Use Premium Capacity Metrics app (Gen1) or Fabric Capacity Metrics (Gen2) for detailed telemetry. Configure Azure Monitor alerts for real-time notifications via email, Teams, or PagerDuty. Additional metrics: dataset refresh duration trends (identify degradation), user concurrency (capacity planning), artifact counts per workspace (governance). Best practice: establish performance baselines during normal operations, alert on anomalies rather than static thresholds—what is normal for Black Friday may be different than summer. Review metrics weekly to identify trends before they become incidents.
How do I set up automated alerts for Power BI refresh failures?
Refresh failure alerting options: (1) Power BI Service built-in—workspace settings → Refresh → enable email notifications for refresh failures (basic, per-dataset), (2) Power Automate—trigger on dataset refresh failure event, send Teams message or create ServiceNow ticket, (3) Azure Logic Apps—poll Power BI REST API for failed refreshes, integrate with ITSM systems, (4) Custom monitoring—scheduled Azure Function queries refresh history via API, alerts on failures. Recommended approach: Power Automate for flexibility and no-code configuration. Sample flow: Monitor Power BI → When refresh fails → condition if business-critical dataset → create high-priority alert in Teams → log to monitoring dashboard. Include in alert: dataset name, workspace, error message, last successful refresh time, owner email. For enterprise monitoring, integrate with existing observability platforms (Datadog, Splunk, New Relic) using Power BI REST API to centralize BI monitoring with application monitoring. Alert fatigue prevention: categorize datasets by criticality, alert immediately for Tier 1, daily digest for Tier 3.
What are the warning signs of Power BI capacity performance degradation?
Early warning indicators before user-visible slowness: (1) Increasing query queue depth—queries waiting to execute, (2) CPU smoothing events—capacity throttling background refreshes to preserve interactive performance, (3) Rising P95 query latency—slowest 5% queries taking longer than baseline, (4) Memory pressure—approaching capacity limits, (5) Refresh duration creeping up—datasets taking longer to refresh week-over-week. Monitor trends rather than single data points—one slow query is noise, steady increase is signal. Root cause investigation: slow queries (use Performance Analyzer), inefficient data models (large tables without aggregations), resource contention (too many workspaces on capacity), under-sized capacity (upgrade from P1 to P2). Prevention: implement capacity reservations (limit workspaces per capacity), use aggregations and incremental refresh, right-size capacity based on actual utilization metrics, conduct quarterly capacity health reviews. Response playbook: detect degradation → identify top resource consumers → optimize or move to separate capacity → scale up if optimization insufficient. Most incidents preventable with proactive monitoring and capacity planning.