A Fabric health check: three questions to ask your tenant
Most Fabric tenants weren’t designed. They grew. Someone started a trial, a few workspaces became a few hundred, a capacity was bought at the size Microsoft suggested, and the settings stayed wherever they were on day one. Nothing is obviously broken, so nobody looks.
Then the renewal comes around, or a report starts timing out at 9 a.m., or someone asks who can see the finance workspace, and nobody can answer with confidence.
A health check answers three questions with evidence instead of opinion. You can make a good start on each one yourself with tools Microsoft already gives you. Here’s where to look.
1. Are we paying for more capacity than we need?
Open the Microsoft Fabric Capacity Metrics app and look at the last two weeks for each capacity. Two charts matter most.
Utilization. This shows how much of your capacity’s compute (its capacity units, or CU) you’re using over time. Long stretches far below the line mean you’re paying for headroom you don’t use. A capacity that sits under a third of its limit most of the day is often a candidate for a smaller SKU, or for pausing outside working hours if it only serves development.
Throttling. Going over 100% for a moment is normal, and Fabric smooths it out. Throttling is what your users actually feel, and it comes in stages:
| Future capacity already used | What Fabric does |
|---|---|
| Up to 10 minutes | Nothing. This is overage protection |
| 10 to 60 minutes | Delays new interactive requests, such as report views, by 20 seconds |
| 60 minutes to 24 hours | Rejects new interactive requests |
| More than 24 hours | Rejects everything, including scheduled refreshes |
If the throttling chart shows regular delays, the answer isn’t always a bigger capacity. Usually one or two items cause most of the load: a semantic model that refreshes every 15 minutes, or a dataflow that reloads ten years of history every night. The app lets you drill into any point in time to see which items and operations were running. Fixing those is cheaper than doubling the SKU.
Two things to keep in mind before you size down. Below F64, every report viewer needs a Power BI Pro license. And the right size depends on your heaviest days, not your average one, so look at month-end too.
2. Which workspaces and items are still in use?
Fabric administrators can open the Govern report in the OneLake catalog. It brings inventory, workspaces, feature usage and sharing together, built on the admin monitoring workspace. The inventory view lists every item in the tenant and marks each one Active or Inactive. Inactive means the audit log has no activity for that item in the last 30 days.
That gives you a clean-up list. Look for:
- workspaces where every item is inactive
- reports nobody has opened in a month, still refreshing a semantic model every hour
- copies of the same report in several workspaces
- orphaned workspaces, which have no admin at all and show up under Govern > Workspaces in the OneLake catalog
Inactive doesn’t always mean unused. A quarterly board report is supposed to sit quiet for two months. But every item on the list should have an owner who can say why it’s there. Stale items that still refresh cost capacity, and stale items that hold data are a security risk with no upside.
3. How do changes move safely from development to production?
Ask your team how a change to a production report gets made. If the honest answer is “someone edits it in Power BI Desktop and publishes over the top”, there’s no history, no review and no way back.
Fabric has two built-in tools for this:
- Git integration connects a workspace to an Azure DevOps or GitHub repository, so every change is committed, reviewable and reversible.
- Deployment pipelines promote content from a development workspace to test and then production, with a comparison of what changed between stages.
You don’t need both on day one, and a small team may not need either for every workspace. But your most important workspaces should have an answer better than “we’re careful”.
While you’re in there: sharing and settings
Three quick checks that often turn up surprises:
- Publish to web. The Embed codes page in the admin settings lists every report published to the open internet. Anyone with the link can see those reports without signing in. Check each one is meant to be public, and check who the tenant setting allows to create new ones.
- External sharing. Review the guest user settings under export and sharing in the tenant settings (OneLake catalog > Govern > Configurations > Tenant settings). Decide on purpose whether people outside your organization can be invited and what they can reach.
- Refresh failures. Look at the refresh history of your most important semantic models. A refresh that has failed every night for three weeks means someone is making decisions on old numbers.
Doing it yourself, or having it done
Everything above can be done by a Fabric administrator with an afternoon to spare. The hard part isn’t finding the data. It’s pulling it together across every capacity and workspace, deciding what matters, and turning it into a short list that someone will act on.
How we do it
Our Fabric Health Check answers these three questions for your whole tenant. It’s read-only from start to finish: your administrator approves our app with read-only access, we collect configuration and usage metadata (never report or table data), and email addresses are anonymized before anything is stored. You get a scorecard, a findings report with prioritized recommendations, and a readout with your team. The Health Check is a fixed $5,000 and takes about two weeks. The Advanced Health Check, at $10,000, adds semantic model and pipeline analysis and sizes your capacity from the measured load of each model and pipeline.
Want something to share with your team? Here’s the one-page overview (PDF). The first 30-minute conversation is free. Book it here.