Power BI Tenant-Level Monitoring - Knowing About Problems Before Your Users Tell You

It's 8:40 on a Monday morning. Reports are loading slowly, or not at all. The first the Power BI admin hears of it is a Teams message from the CEO's executive assistant. The admin spends twenty minutes checking gateways, refresh history and capacity metrics before somebody thinks to look at Microsoft's status page, where an incident for the Australia East region has been posted for half an hour.

It's a common story, and the fix isn't technical. It's knowing where Microsoft publishes this information and making sure the right people are subscribed to it.

I recently wrote about tenant-level auditing, which is about capturing what your users do. Monitoring is the other half. Microsoft's guidance defines it as the ongoing activities that tell you what's happening, usually with alerting involved. Their tenant-level monitoring article is one of the shorter ones in the implementation planning series, and a lot of it is a list of places to look. That's more useful than it sounds, because most admins we meet know about two of them.

Service health - four places, one habit

When something seems broken, the guidance says to check these before raising a support ticket with Microsoft.

The Power BI support site. support.powerbi.com is public and shows the current service status, outage and degradation notices, and general awareness messages. Anyone can open it, including your users, so it's worth putting the link in your internal Power BI help page.

The Fabric known issues page. This lists active and recently closed known issues. Some are bugs other customers have reported. Some are behaviours that are by design but generated enough support tickets that Microsoft wrote an explanation. Before you burn a day diagnosing something strange, search here.

The Microsoft 365 admin centre. Service health shows advisories (limited impact, service still available) and active incidents (something major is unavailable or badly degraded). For each incident you get the user impact, status, estimated time to resolve, when the next update is due and, once it's closed, the root cause. The history goes back 30 days.

The Power BI issues site in the community forum. Users report problems publicly here. It's noisy, but if twelve people posted about the same error in the last hour, you know it's not just you.

The catch with the admin centre is permissions. Power BI administrators only get a limited view of Microsoft 365 service health and the message centre. In plenty of Australian organisations the Power BI admin sits in a data team, the Microsoft 365 admin sits in infrastructure, and incident notices land with someone who doesn't know which ones matter for BI. The guidance's checklist includes "review administrator roles" and this is why. A Service Support Administrator role assignment, or just an agreed forwarding rule, closes that gap.

Turn on the outage emails

There's a tenant setting called "Receive email notifications for service outages or incidents". It sends an email when there's an outage or degradation affecting your tenant. It takes two minutes to enable, and plenty of the tenants we review have never switched it on.

Two things to know. It only applies to workspaces on capacity (Premium or Fabric), so Pro-only tenants don't get it. And it requires a mail-enabled security group. Microsoft suggests naming it something like "Power BI System Support" and adding your Power BI admins, key Centre of Excellence people and the help desk.

Don't add all your users to that group. Microsoft's notices are written for administrators and they'll confuse everyone else. The guidance recommends that your own team sends a rewritten message in plain language through whatever channel people read, usually a Teams channel. I agree. "Reports may be slow this morning due to a Microsoft issue, we're watching it, no need to log a ticket" does more for user confidence than a forwarded incident ID.

Security and data protection monitoring

The article opens with this, and it's the area where Power BI admins have the least direct control, because the tools belong to the security team.

Sensitivity labels and DLP. Labels from Microsoft Purview classify content. Data loss prevention policies then detect risky sharing of sensitive data, alert admins, and show policy tips to users while they work. From a monitoring point of view, DLP alerts are a signal you want someone to be reading.

Defender for Cloud Apps. This is where the interesting Power BI controls live. You can block downloads of content carrying a particular sensitivity label, get an alert when a tenant setting changes, detect unusual behaviour such as a burst of sharing operations or large downloads, and flag sessions where the same account connects from two countries in a short time.

Microsoft Sentinel. Sentinel has a Power BI data connector that streams a subset of audit log attributes into Log Analytics. Security teams can then write detection rules and automate responses with playbooks.

My honest view is that these are valuable and underused, and the reason is organisational. They're separately licensed, separately secured, and Power BI admins don't automatically have access. Microsoft says as much in the article and recommends working with your infrastructure team. In practice this means the BI lead has to walk over to the security team and say "here are the five Power BI events I'd like alerts for". Start with tenant setting changes and bulk exports of labelled content. Security teams are usually happy to help, they just don't know Power BI well enough to guess what matters.

One caution on the Sentinel connector. It carries a subset of attributes. It doesn't replace extracting the full activity log for your own auditing.

Releases - the monitoring nobody thinks of as monitoring

You can control when Power BI Desktop updates reach user machines. You have no control over when the Power BI service changes. It updates continually, and occasionally a change alters how something looks or behaves in a way your users notice before you do.

The guidance recommends watching:

• The Power BI blog, especially the monthly feature summary post
• The release plan, which Microsoft organises in two semesters a year, April to September and October to March
• The Microsoft 365 message centre, which announces planned changes ahead of time
• The Desktop change log for quick-fix releases that land outside the monthly cycle
• The ideas site, to see what other customers are asking for

Someone on your team should own reading the monthly blog post. It takes half an hour. The output should be a short note to your content creators: here's what changed, here's what to try, here's what to be careful with. A five-minute segment in a monthly community of practice call works well for this, and people do pay attention to it.

On Desktop versions, a practical tip. If half your creators are on the Microsoft Store version that updates itself and half are on an MSI that IT packaged six months ago, you'll get files that open for some people and not others. Pick one distribution method. We generally suggest the Store version unless there's a specific reason to hold updates back.

The message centre also sends telemetry-driven notices. Microsoft's example is a reminder that Internet Explorer is no longer supported, sent because they detected people in your tenant using it. Those targeted messages are easy to dismiss and usually worth acting on.

Your Azure dependencies

The last section of the article lists the Azure services a Power BI tenant commonly depends on, and points to the Azure status page. It's a list I'd encourage every admin to write out for their own environment:

• Microsoft Entra ID, which every sign-in depends on
• Azure storage accounts used for dataflow storage or semantic model backups
• Azure Log Analytics, if you've connected workspaces for model event logs
• Virtual machines hosting on-premises data gateways, or VNet data gateways
• Azure Key Vault, if you bring your own encryption keys
• Microsoft Purview
• The data sources themselves: Azure SQL, Synapse, Analysis Services

When a refresh fails at 6am, the cause is the gateway VM or the source database far more often than Power BI itself. The Microsoft article doesn't go deep on gateway monitoring, which I think is a gap. In our experience the gateway is the single most common point of failure in a hybrid setup, and it deserves proper monitoring: CPU and memory on the VM, an alert when the gateway service goes offline, and a cluster of at least two nodes for anything the business relies on.

The article also doesn't cover capacity monitoring in any detail. If you're on Fabric capacity, the Capacity Metrics app and throttling alerts belong in your monitoring plan too. They're covered elsewhere in Microsoft's docs, but don't read this one article and assume you're done.

A monitoring plan that fits on a page

Microsoft's checklist boils down to: educate your admins, write a monitoring plan, write a user communication plan, decide who gets the emails, review admin roles, and look into the security tooling. For a mid-sized organisation, here's roughly what we set up:

1. Enable the outage notification setting with a small support group.
2. Give the Power BI admin read access to Microsoft 365 service health and the message centre.
3. Agree who tells users what, and through which channel, when there's an incident.
4. Assign one person to read the monthly release post and summarise it.
5. Ask the security team for a few Defender for Cloud Apps alerts, starting with tenant setting changes.
6. List your Azure and gateway dependencies and put basic alerts on them.

That's a day or two of work. It won't stop Microsoft having an outage, but it changes the Monday morning story. The admin knows first, a message goes out before the tickets arrive, and nobody wastes an hour restarting gateways that were never the problem.

If you don't have the people to watch all this, that's common, particularly where one person administers Power BI alongside three other jobs. It's part of what our Power BI consultants set up during tenant reviews, and for organisations that want someone else keeping watch on an ongoing basis, we offer it through our managed services. If you're moving onto Fabric and want monitoring designed in from the start, have a look at our Microsoft Fabric consulting page or get in touch.