The request usually arrives as one line: managed Fabric, 24/7 support, with an SLA. It reads like one requirement. In practice it is three, and Microsoft already provides two of them, at least in part. The third, which is the one the business actually cares about, nobody provides by default.
That is the useful frame for buying Fabric managed services. Before comparing providers, separate what Microsoft operates from what someone in your organisation, or a partner, still has to run every day.
What Microsoft’s 99.9% actually covers
Fabric carries a financially backed availability commitment in Microsoft’s Online Services SLA. Below 99.9% monthly uptime you get a 10% service credit, and below 99% you get 25%. It is a real commitment. It is also narrower than most people assume.
For Data Factory, the covered features are Dataflow Gen2 refresh and the ability to “Open Pipelines in the service”. Opening a pipeline counts. Whether it runs successfully does not. Downtime excludes time “due to Microsoft Fabric throttling policy”, so a capacity that is throttling because your own workloads overran it is not an outage. Preview features are not eligible at all.
The remedy is a service credit, which is the “sole and exclusive remedy”, and you have to claim it. The claim needs the times, the duration, the affected resources and the errors, by the end of the following month. An estate with no monitoring of its own cannot evidence a claim, which makes the SLA worth less to exactly the organisations that most need it.
So when 99.9% appears in a Fabric proposal, ask what it covers. Microsoft’s figure is for the platform, it excludes throttling and previews, and it pays out only as a credit you claim.
What Microsoft means by 24/7 support
The second half of the request is break-fix support, and here too the round-the-clock part is narrower than the phrase suggests. Microsoft’s support options for Power BI and Fabric provide 24/7 help only for Severity A. The one-hour response needs “work stoppage in existing production reporting”. Other cases are handled during business hours, depending on your support plan.
There is no “direct SLA for support request resolution”, only for the first response. In our experience, when the cause is a Fabric platform issue, the fix depends on Microsoft, and it can take from a couple of hours to several depending on severity. And two things a data team most often needs are out of scope: data recovery, and writing or debugging customer code. Microsoft “doesn’t provide assistance for correcting damaged data.”
None of this is unreasonable. It is the platform vendor’s job to keep the platform up, and Microsoft’s shared responsibility guidance says so plainly: Microsoft is responsible for core platform reliability, and the customer is responsible for choosing and using the reliability features. The gap is what sits on the customer’s side of that line.
The third thing: data that lands on time
What the business means by “24/7” is almost never platform availability. It means the finance dashboard is right at 8am, the overnight load finished, and someone noticed before the CFO did when it did not.
That is an outcome, and Microsoft’s commitments stop short of it by design. A pipeline that fails at 3am because a source system changed a column is not downtime. A semantic model that refreshed on stale data is not a support case Microsoft can fix. Data that lands correctly before a named business deadline is the one thing nobody provides unless someone is explicitly accountable for it.
What running Fabric involves, surface by surface
For each operational area, Microsoft provides tools. Someone still has to run them, and several of the tools have gaps that only show up after go-live.
| Surface | What Microsoft gives you | What someone still has to run |
| Capacity | The Capacity Metrics app, capacity events, surge protection | Alerting on throttling, and acting before users feel it |
| Failures | The Monitor hub, failure emails, workspace monitoring | Triage, rerun, and fixing the cause, across manual and scheduled runs |
| Platform telemetry | The admin monitoring workspace, the activity log | Keeping the workspace refreshing, exporting logs before they expire |
| Tenant settings | The admin portal and the List Tenant Settings API | Noticing when a setting changes, by snapshot and comparison |
| Access | Workspace roles, OneLake security roles | Reviewing who can read what, on a schedule |
| Continuity | Platform failover, OneLake replication when enabled | The recovery runbook for everything outside that |
| Cost | Pause and resume, reservations | Deciding which capacities pause, and watching consumption changes |
The gaps are specific, and worth knowing before a provider tells you they are covered.
The Capacity Metrics app cannot alert anyone. Microsoft’s documentation says it “doesn’t support alerts or notifications”, keeps 14 days, and data arrives 10 to 15 minutes late. Alerting on throttling means wiring capacity events into Activator, which is best effort and does not backfill. And on a capacity created today, heavy load may show up as cost before it shows up as throttling: capacity overage is now enabled by default when a capacity is created, and it charges usage that would otherwise be throttled at three times the pay-as-you-go rate, up to a rolling 24-hour threshold that defaults to 25%. The mechanics of throttling itself are covered in our capacity planning article.
Failure emails cover less than they appear to. Fabric’s built-in schedule failure notifications apply only to scheduled runs, not manual runs, cannot go to an external email address, and do not yet cover semantic models. Semantic models have Power BI’s own refresh failure email, but by default it goes only to the model’s owner, only the owner can change the model’s refresh settings to add anyone else, and on-demand or programmatic refreshes do not trigger it. The Monitor hub and its job alerts are both in preview.
Workspace monitoring watches from inside the capacity it monitors. Workspace monitoring is off by default, does not backfill earlier activity, keeps 30 days, and uses Fabric capacity. Microsoft states that Activator alerts built on it “can be throttled”. When the capacity is in trouble, the alert about the trouble can be delayed by the same trouble.
Platform telemetry can quietly stop. The admin monitoring workspace refreshes daily, and its scheduled refresh fails if the admin who first opened it is no longer an admin. Under Privileged Identity Management, that admin’s access must be active at refresh time. The activity log keeps 28 days, not the 30 often quoted, so anything you need for an audit trail has to be exported.
Access controls do not do what their names suggest. OneLake security default roles apply only to Viewers. A read-write role granted to an Admin, Member or Contributor has no effect, because those roles already have full access. An access review therefore has to start from workspace membership, and Microsoft’s own access reviews need Entra ID Governance or Entra Suite licences.
Costs can change without anyone changing anything. From 15 October 2026, Spark-driven OneLake operations count towards capacity consumption, and Microsoft notes some customers “might see increased CU consumption”. Someone has to check that against capacity headroom before it shows up as throttling.
Continuity is partly Microsoft’s and partly yours. In a regional outage, Microsoft initiates the failover, typically in under an hour, but writes are paused and Power BI refreshes are not supported afterwards. After a zone outage, Spark jobs may need resubmitting. What replicates and what does not is the subject of our Fabric disaster recovery article.
What to ask before buying Fabric managed services
Availability and break-fix are Microsoft’s. What a provider adds sits in what Microsoft does not cover, and two questions show quickly whether that has been thought through.
- Who hears about a failed refresh? Manual runs fall outside Fabric’s free failure emails, on-demand and programmatic semantic model refreshes fall outside Power BI’s, and even a scheduled model refresh alerts only its owner unless the owner adds the team.
- Which of your runbooks depend on preview features? The Monitor hub, job alerts and workspace-level surge protection are all in preview, and previews sit outside the SLA.
The commercial question of whether to buy a managed service at all, and what it should and should not include, is the one Anuj sets out in managed service versus project delivery. This article is about what the service has to do once you have decided.
What we see after go-live
The commonest gap we see after go-live is not a missing tool. It is that nobody is named as accountable for freshness, so failures are discovered by the people reading the reports. BI teams typically set alerts on ETL failures but not on semantic model refreshes, so when a model’s refresh fails, the first to know is whoever opens the report.
The next most common is throttling, and most of the throttling nobody planned for comes from end users rather than pipelines. Opening a report or selecting a slicer is an interactive operation, which Fabric smooths over five to 64 minutes against 24 hours for background jobs, so a heavy morning of report use fills the headroom fast, and the pattern changes from day to day and across the month. After that comes self-service: users allowed to create their own items consume capacity that nobody is monitoring until everything is choked.
Where the architecture is sound, refresh failures are rare and what remains is mostly capacity. Across the three Fabric estates we have worked on over the last two years, roughly 80% of failures were throttling and 20% were Microsoft infrastructure issues. Three is a small base, so treat that as a direction rather than a benchmark.
Where to start
- List your critical datasets and when each one is needed. That is where monitoring should start.
- Wire throttling alerts through capacity events, and ask each critical semantic model’s owner to add the team to its refresh failure emails.
- Check who opened the admin monitoring workspace, and export the activity log before it ages out.
- Check consumption after 15 October if you run Spark against OneLake.
Veratas runs Microsoft Fabric estates after go-live as part of our managed services. If you are comparing providers, or trying to work out what yours actually covers, talk to our team.
Frequently asked questions
Does Microsoft provide an SLA for Fabric? Yes. The Online Services SLA gives a 10% service credit below 99.9% monthly uptime and 25% below 99%. For Data Factory it covers Dataflow Gen2 refresh and opening pipelines, not whether runs succeed, and it excludes throttling and preview features.
Does Microsoft offer 24/7 support for Fabric? Only for Severity A, which needs a work stoppage in production reporting. Other cases are handled in business hours depending on your plan, there is no committed resolution time, and data recovery and debugging customer code are out of scope.
Can the Capacity Metrics app alert us when a capacity throttles? No. Microsoft states it does not support alerts or notifications. Throttling alerts are built from capacity events through Activator.
Who finds out first when a semantic model refresh fails? Often the person reading the report. Teams tend to alert on ETL failures but not on semantic model refreshes, and Power BI’s own refresh failure email goes only to the model’s owner by default and is not sent for on-demand or programmatic refreshes.
Does capacity overage stop Fabric throttling? Up to a point. It is on by default for new F capacities and pays for usage that would otherwise be throttled, at three times the pay-as-you-go rate, until a rolling 24-hour threshold is reached, 25% by default. After that, throttling resumes.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.