Office365Mon and Power BI - Monitoring Microsoft 365 Health the Sensible Way

Every so often a client asks us a version of the same question. Their Microsoft 365 tenant had a wobble, Outlook was slow for an hour, Teams dropped calls, and nobody could tell them afterwards whether it was Microsoft's fault or something on their side. They want a dashboard. Something that tells them, in plain numbers, how often 365 is actually up, how fast mail is really flowing, and whether the service they pay a fortune for is delivering what it promises.

For a good few years, one of the answers to that question was a product called Office365Mon, and it had a tidy little integration with Power BI. The Microsoft documentation for the Office365Mon connector still exists, and people still find it, click through, and wonder why nothing works. So this is worth writing about, partly to save people the wasted afternoon, and partly because the underlying need has not gone anywhere even though the tool has.

What Office365Mon actually did

Office365Mon was a third-party service, not a Microsoft product, that sat outside your tenant and probed it constantly. It would send test requests to Exchange Online, SharePoint, and the other 365 workloads, measure whether they responded and how quickly, and log the results. When something went down, it could alert you. Over time it built up a history of uptime and performance that was genuinely useful, because it measured your tenant from the outside, the way a real user in a branch office would experience it, rather than trusting Microsoft's own status page.

The Power BI piece was a content pack. You connected Power BI to your Office365Mon subscription, it pulled your monitoring data in, and you got a pre-built dashboard and report showing outages, response times, and health trends over time. For an IT manager who wanted to walk into a meeting and say "here is our 365 availability for the quarter, here are the three incidents, here is how long each lasted," it did the job without anyone having to build the reporting from scratch.

That external perspective was the clever bit. Microsoft's Service Health dashboard tells you what Microsoft thinks is broken. It does not always match what your users are living through, especially for issues that are regional, or specific to your network path, or too small for Microsoft to declare an incident. An independent monitor catches the stuff that never makes it onto the official status page.

Why it is gone, and why that matters

Here is the honest part. Office365Mon as a service wound down. The Power BI content pack model it relied on has also been retired by Microsoft, replaced by the newer template apps and standard connector approach. So if you land on that documentation page today expecting to wire up a live dashboard, you are chasing something that is not there anymore. I have watched people burn real time on this before they realise the whole thing is a museum piece.

I am not writing this to bury a product. I am writing it because the reason people wanted Office365Mon is exactly as valid in 2026 as it was when the tool launched. Australian businesses run enormous chunks of their operation on Microsoft 365. When it degrades, work stops, and "was it us or them" is a question that costs money to answer badly. The tool retired. The problem did not.

How we handle 365 monitoring now

When a client comes to us wanting visibility into their Microsoft 365 health, the modern stack looks quite different, and frankly better, than the old content-pack approach.

The first source is Microsoft's own telemetry, exposed through the Microsoft Graph API and the Service Communications API. Your tenant generates a lot of health and usage data, and you can pull it programmatically: service health incidents, message centre notices, mail flow statistics, Teams call quality, SharePoint activity. This is data you already own, sitting behind an API, waiting for someone to shape it into something a human can read.

The second source, for that outside-in view Office365Mon gave you, is synthetic monitoring. You stand up a small probe, in Azure or wherever, that regularly tests the workloads that matter to you and records latency and success. It is the same idea Office365Mon sold, except now you own it, you control what it tests, and it is not going to disappear when a vendor decides to shut the doors.

Then Power BI does what it has always done well. You land both streams into a model and build a report that answers the real questions: what is our rolling 365 availability, which workloads are the weak spots, are incidents trending up or down, and how does our lived experience compare to what Microsoft is reporting. Because you control the pipeline, you can also blend in things Office365Mon never touched, like helpdesk ticket volumes during outages, so you can show the actual business impact rather than just a red dot on a timeline.

This is very much the kind of work we do on our Power BI consulting engagements. Not the pretty charts, though those matter, but the plumbing underneath that makes the charts trustworthy. A monitoring dashboard nobody believes is worse than no dashboard, because it gives false confidence, and getting the data model and the refresh right is where the believability comes from.

The trap of monitoring for its own sake

A word of caution, because I have seen this go wrong. It is easy to get excited about 365 monitoring, build an elaborate dashboard with forty visuals, and then have precisely nobody look at it after week two. Monitoring only earns its keep when it drives a decision or an action.

So before we build anything, we ask what the dashboard is actually for. If it is for the IT team to catch problems early, it needs alerting, not just a pretty historical report, and it needs to be pointed at the workloads your business genuinely depends on rather than everything. If it is for leadership to hold Microsoft accountable or justify the licensing spend, it needs to be simple, quarterly, and framed in business terms, not milliseconds of latency. Those are two different products, and trying to build one thing that serves both usually produces something that serves neither.

The other honest caveat: a lot of 365 slowness that gets blamed on Microsoft is actually local. Your internet link, your firewall, a dodgy DNS setup, an old Outlook profile. Good monitoring should help you tell the difference, which is exactly why the external synthetic probe matters. Without it, every dashboard just shows "something was slow" and points no fingers, which helps nobody.

Where this fits a broader data strategy

Monitoring 365 health is rarely a project on its own. It usually surfaces when a business is already thinking harder about its data: getting operations onto Power BI, building proper reporting, working out which of the numbers flying around the organisation can actually be trusted. Service health is one dataset among many, and the same discipline that makes a sales dashboard reliable makes an uptime dashboard reliable.

That is why we tend to fold this into wider business AI and data services rather than treating it as a standalone widget. Once you have a clean, well-governed pipeline feeding Power BI, adding 365 health telemetry to it is a modest extra step, not a separate build. And once the reporting exists, keeping it accurate over time, as Microsoft changes APIs and your tenant evolves, is the sort of ongoing job a managed data service is designed to carry so it does not quietly rot the moment the person who built it moves on.

The bottom line

Office365Mon was a decent answer to a real question, and its Power BI integration made Microsoft 365 health legible to people who needed it. It is gone now, and the documentation that points to it is a dead end, so if that is what brought you here, stop looking for the old connector.

The need behind it is completely current. You can build better 365 health visibility today than Office365Mon ever offered, using data you already own through the Graph and Service Communications APIs, a small synthetic probe for that outside-in view, and Power BI to tie it together. The difference is you own the whole thing, so it will not vanish when a vendor changes their mind.

If your Microsoft 365 tenant has ever had a bad day and left you unable to say afterwards exactly what happened or how often it happens, that is a solvable problem and a fairly satisfying one to solve. Have a look at what we do around Power BI, or get in touch and we will help you build monitoring that people actually trust and use.