Why moving your semantic layer to a separate data platform might not be the obvious choice it seems.

Disclaimer: The opinions expressed in this post are my own and do not represent the views of my employer.

The Debate in 30 Seconds

The analytics industry is in a heated argument about where your business metrics should live:

• Camp A (BI-Tool-Centric): Define your semantic model in your BI tool. It’s where your users already are.
• Camp B (Data-Platform-Centric): Define your semantic layer in the data platform. Let every downstream tool consume it.

Camp B has been gaining momentum across the industry. This post walks through seven dimensions to help you critically evaluate both approaches before making a strategic decision.

A Note on Terminology

These two terms are often used interchangeably, but they mean different things:

• Semantic model — A concrete implementation: tables, relationships, measures, hierarchies, and business logic bundled into a queryable model. In Power BI, this is the semantic model (formerly “dataset”). It’s where your KPIs, time intelligence, and row-level security actually live.
• Semantic layer — The broader architectural concept: an abstraction that maps business terms to underlying data so consumers don’t need to know table structures or write raw SQL. In Power BI, most often the semantic layer sits on top of one or more semantic models, but it can also incorporate other data sources — lakehouses, warehouses, APIs, or real-time streams.

Throughout this post, “semantic model” refers to the BI tool’s implementation, while “semantic layer” refers to the platform-level abstraction.

1. Maturity & Capability

Key question to ask: “Can your semantic layer handle the 20 most complex measures in our current BI model? Show me.”

2. Performance

Key question: “When a business user applies three slicer filters on a 50M row dataset through your semantic layer — how fast does it respond in the slowest realistic scenarios, not just on average?”

3. The “Last Mile” Problem

Even if you externalize metric definitions, the BI tool still needs:

• Conditional formatting rules
• Visual-level filters and default aggregations
• Display folders and field organization
• Synonyms and linguistic metadata (for Q&A / NLP)
• Report-level measures and layout-specific logic

The platform semantic layer doesn’t eliminate BI-tool-specific work. It just splits your logic across two places.

You still maintain the BI tool. Now you also maintain the platform layer. That’s not simplification — that’s added complexity.

4. Governance

Key question: “When a business user disputes a number, can they trace the metric definition themselves — or do they need to file a ticket with the data platform team?”

5. The AI Agent Angle

This is the emerging frontier. AI agents need semantic context to reason about data. The question is: which semantic layer feeds them?

Key question: “If my AI agent and my BI report give different answers for the same KPI, which one is wrong — and whose job is it to fix it?”

6. The Lock-In Reality

A common argument against BI-tool semantic models is lock-in. Let’s be honest about what’s really happening:

Key question: “If I adopt your semantic layer and want to switch data platforms in 3 years, how portable are my metric definitions?”

7. Who Actually Has This Problem?

The platform-centric approach assumes you need one semantic layer serving many BI tools. But ask yourself:

• How many BI tools does your organization actually use at scale?
• Of those, how much genuine metric overlap exists between them?
• Is the overlap large enough to justify an entirely new architectural layer?

For most enterprises, the honest answer is: we’ve standardized on one BI tool, and the multi-tool problem is theoretical. The platform semantic layer is an elegant solution to a problem you probably don’t have.

The Decision Framework

To make this actionable, here’s a decision tree that walks you through the key questions. Follow the green path — if you keep answering “Yes,” you’ll end up where most enterprises belong.

✅ Stay BI-Tool-Centric When:

• You’ve standardized on one primary BI tool
• You have deep investment in existing semantic models
• Business users own and validate metric definitions
• Interactive query performance is critical
• Your AI/agent strategy can sit on top of the BI model
• You don’t have a genuine multi-tool consumption problem

⚠️ Consider Data-Platform-Centric When:

• You genuinely operate 3+ BI tools with significant metric overlap
• Your primary consumers are programmatic (APIs, agents, apps) rather than visual
• You’re early in your analytics journey with no entrenched BI semantic model
• You’re willing to accept the added complexity and governance overhead

Bottom Line

The data-platform semantic layer movement solves elegantly for a scenario that affects a minority of organizations, while introducing architectural complexity, governance fragmentation, and performance trade-offs for everyone else.

Before you rearchitect your semantic layer because you were told it’s “strategic,” ask the hard questions above. The answer for most enterprises today is: your BI tool’s semantic model is already the foundation of your semantic layer — and that’s not a weakness. It’s a huge strength.

For a deeper technical perspective on why stacking semantic models on top of each other doesn’t work, I highly recommend Chris Webb’s post Power BI And Support For Third Party Semantic Models. He explains the architectural reasons why — from SQL generation assumptions to metric aggregation conflicts — putting one semantic model on top of another creates fundamental problems that aren’t specific to any single tool.

Don’t let industry narratives make your architecture decisions. Let your users, your governance model, and your actual consumption patterns guide you.

Every Power BI semantic model starts clean. But over time — as measures pile up, relationships multiply, and formatting inconsistencies creep in — models silently degrade. By the time someone notices a slow report or a questionable DAX pattern, the damage is already done.

What if your models could check themselves — every week, automatically — and write the results to a place where you can query, compare, and trend them over time?

That’s exactly what this Fabric Notebook does. It combines three analyses into one script, saves everything to a Lakehouse, and runs on a schedule. No manual effort after the initial setup.

Why Run BPA and Memory Analyzer Together?

Microsoft Fabric comes with two built-in analysis notebooks: the Best Practice Analyzer (BPA) and the Memory Analyzer (also known as Vertipaq Analyzer). Most people run them separately, if they run them at all. But running them together gives you the full picture of your model’s health:

• BPA catches structural problems — missing format strings, duplicate measures, hidden foreign keys not set, unused objects, DAX anti-patterns. It tells you what’s wrong with how the model is built.
• Memory Analyzer shows you where the weight is — which tables, columns, and segments consume the most memory. A model can pass every BPA rule and still be bloated because of high-cardinality columns or unnecessary detail data.

Together, they answer both questions: “Is this model built correctly?” and “Is this model built efficiently?”

On top of that, the script also captures seven INFO.* DAX system views — tables, columns, measures, relationships, storage tables, storage columns, and storage segments. These are the raw metadata that power tools like DAX Studio’s Vertipaq Analyzer, but now they live in your Lakehouse as queryable Delta tables.

Direct Lake Models: What You Need to Know

This notebook works with both Import and Direct Lake semantic models — but the Memory Analyzer results mean different things depending on which mode you’re using.

Import Models: Stable, Predictable Memory

For Import models, memory analysis is straightforward. The entire dataset is loaded into memory at refresh time and stays there. When you run Memory Analyzer, you see the full footprint — every table, every column, every segment. The results are stable and reproducible.

Direct Lake Models: Dynamic, Query-Driven Memory

Direct Lake models load data on demand — only the columns and rows that are actually queried get paged into memory. This means the Memory Analyzer shows you a snapshot of what’s currently cached, not the theoretical maximum size of the model.

If you run the analysis right after opening the semantic model, you’ll see almost nothing in memory — the cache is cold. To get realistic memory metrics for a Direct Lake model:

1. Warm up the cache first. Run your most common reports or execute representative DAX queries to load the frequently accessed columns.
2. Run the notebook after typical usage. Schedule it for a time when the model has been actively queried during business hours — not at 3 AM when the cache is empty.
3. Interpret the results as “working set” size. The memory footprint you see reflects what’s needed to serve recent queries, not the full lakehouse table size. This is actually more useful for capacity planning — it tells you the realistic memory demand.

BPA rules, on the other hand, work identically for both Import and Direct Lake — they analyze the model’s structure (measures, relationships, formatting), not the data in memory.

The Three-Step Pipeline

The notebook runs sequentially through three steps:

Step 1: Best Practice Analyzer

Uses fabric.run_model_bpa() to evaluate the semantic model against the standard rule set. Results include the rule category (Formatting, Maintenance, Performance, DAX Expressions), severity, affected object, and a description of the issue.

Step 2: Memory Analyzer

Uses fabric.model_memory_analyzer() to produce a tabbed summary: Model Summary, Tables, Partitions, Columns (Total Size), Columns (Temperature), Relationships, and Hierarchies. This is the same analysis DAX Studio provides — but running directly inside Fabric.

Step 3: DAX INFO Views

Seven EVALUATE INFO.*() queries capture the full internal metadata of the model and save each as a Delta table:

• INFO.TABLES() → table-level metadata (row counts, modified times, storage IDs)
• INFO.COLUMNS() → column-level details (data types, cardinality hints)
• INFO.MEASURES() → all measures with their DAX expressions
• INFO.RELATIONSHIPS() → relationship definitions and cardinality
• INFO.STORAGETABLES() → physical storage table metadata
• INFO.STORAGETABLECOLUMNS() → storage-level column statistics
• INFO.STORAGETABLECOLUMNSEGMENTS() → segment-level compression details

Each result set gets an analysis_timestamp, model_name, and workspace_name column appended before saving — so you can track multiple models over time in the same Lakehouse.

Why Save to a Lakehouse?

Running an analysis notebook and looking at the output once is useful. But the real value comes from persistence:

• Trend analysis. When BPA results are appended weekly, you can track whether your model is getting better or worse. Did someone introduce 12 new unformatted measures last sprint? You’ll see it.
• Cross-model comparison. Run the same notebook against multiple semantic models (just change the configuration variables). Query all results in one place to find which models need the most attention.
• SQL Analytics Endpoint. Every Delta table in a Fabric Lakehouse is automatically exposed via a SQL endpoint. That means you can query BPA results from SSMS, Azure Data Studio, or even build a Power BI report on top of your model health data.
• Audit trail. When stakeholders ask “how has model quality improved this quarter?”, you have the data to answer.

Why Schedule It?

A one-time health check is a snapshot. A scheduled health check is a monitoring system.

Fabric Notebooks support native scheduling — no Data Factory pipeline needed. From the top ribbon, click Schedule, set it to Weekly, pick a day and time, and save. The notebook runs unattended, appends results to your Lakehouse, and you’re done.

This means:

• No manual intervention. Models are checked every week without anyone clicking “Run”.
• Early warning system. New BPA violations show up within a week of being introduced.
• Memory regression detection. If a model’s memory footprint suddenly doubles after a data source change, the INFO tables will show it in the next scheduled run.
• Compliance documentation. Some organizations require periodic checks on data model quality. A scheduled Lakehouse write creates an immutable record.

Setup: Five Minutes to Automated Model Monitoring

Here’s the complete setup process:

1. Create a Lakehouse in your Fabric workspace (or use an existing one).
2. Create a new Notebook and attach the Lakehouse as the default (left panel → Lakehouses → Add).
3. Paste the script from GitHub or the Fabric Community Notebook Gallery.
4. Set the three config variables:

dataset = "Your Semantic Model Name"
workspace = "Your Workspace Name"
lakehouse = "Your_Lakehouse_Name"

5. Run once to verify everything works.
6. Schedule via Run → Schedule → Weekly.

The full notebook code is available on GitHub.

What You Get: 8 Delta Tables

After a successful run, your Lakehouse contains:

Each table includes analysis_timestamp, model_name, and workspace_name columns — so you can filter, compare, and trend across models and time periods.

Credits

The DAX INFO.* views approach was inspired by Hariharan’s Vertipaq Analyzer queries. SQL view equivalents are available in my PBI-Tools repository. Thanks to Bernat Agulló for pointing me in the right direction.

Resources

• GitHub: Notebook (latest version with fix)
• Fabric Community: Notebook Gallery Post
• GitHub: SQL Views for Vertipaq Analyzer

Why moving to Microsoft Fabric is like upgrading from a small airstrip to a world-class airport

The full picture: Seven areas where Fabric elevates your Power BI environment

Imagine your Power BI environment is an airline. Reports are your fleet, data models are your engines, and your team — the analysts, developers, admins — are the pilots and ground crew keeping everything in the air.

For years, the operation has worked. Flights depart, passengers arrive, the business gets its data. But behind the scenes, things are starting to strain. Deployments feel like taxiing without instruments. Troubleshooting means searching through scattered flight logs. And when someone asks “can we do AI?”, you realize your runway is too short for the next generation of aircraft.

Microsoft Fabric is the airport upgrade. Not a different airline — the same planes, the same crew — but with a modern terminal, a control tower, proper hangars, and a runway long enough for whatever comes next.

Let me walk you through seven areas where this upgrade changes everything.

1. Training in the Flight Simulator — A Professional BI Environment

Before your reports go live, they train in the simulator

No airline would let a pilot fly passengers after just one practice run. Yet in many Power BI environments, that’s exactly what happens: changes go straight to production. A modified DAX measure, an updated data model, a new page — deployed directly to the live report that hundreds of users rely on.

Fabric introduces the flight simulator — a proper DEV → QA → PRD lifecycle.

• Development (DEV): Build and experiment freely in an isolated workspace. Break things. Try new approaches. No one sees it until you’re ready.
• Quality Assurance (QA): Test with real data, validate with stakeholders, catch issues before they matter.
• Production (PRD): Deploy with confidence through Deployment Pipelines — automated, controlled, reversible.

On top of this, Fabric enables full Git integration. Every change to a report, semantic model, or notebook is version-controlled. You can see who changed what, when, and why. And if something goes wrong? Rollback in seconds — not hours of panicked troubleshooting.

Add CI/CD pipelines with code review, and you have a deployment process that matches what software engineering teams have enjoyed for decades. No more manual risk. No more “who published that change?”

In aviation terms: Your pilots now train in a simulator before every flight, and every procedure is documented in a flight manual that the entire crew can reference.

2. Upgrades in the Hangar — Better Power BI Reports

The hangar is where your reports get tuned for peak performance

Every aircraft needs regular maintenance. Engines are inspected, instruments recalibrated, performance data reviewed. Without a proper hangar? Maintenance happens on the tarmac, in the rain, with improvised tools.

That’s been the reality for many Power BI environments. Analyzing model performance meant installing third-party tools like Tabular Editor and DAX Studio, configuring XMLA endpoints, and relying on experts who knew the process by heart. Powerful — but fragile and inaccessible to most team members.

Fabric changes this by integrating Vertipaq Analyzer and Best Practice Analyzer (BPA) natively into the platform. What used to require multiple tools and expert configuration now takes just a few clicks:

1. Open your semantic model in Fabric
2. Click on BPA or Memory Analyzer
3. Run the notebook

That’s it. The same deep analysis — column-level memory consumption, rule violations, data type issues — now accessible to the entire team.

But the hangar offers more than diagnostics. With Fabric Notebooks, you can automate report optimization — fix formatting issues, apply best practices, even replace poor visualization choices programmatically. And with pre-built templates, new reports start from a solid foundation instead of a blank canvas.

In aviation terms: Your hangar now has state-of-the-art diagnostic equipment, automated maintenance routines, and a parts catalog that ensures every new aircraft starts with the right configuration.

3. Cargo Jet Capacity — OneLake for Everyone

OneLake: One airfield, all cargo — no matter where it originates

Ever been at the airport with a suitcase that’s 24 kg? Sorry, 23 kg max — you’re not getting on that plane. Repack, leave something behind, or pay extra.

That’s Power BI Pro with its 1 GB model limit. Your data doesn’t fit? Too bad — repack, split, or leave data behind. And on top of that: max 8 refreshes per day, data duplicated across models.

OneLake — Fabric’s unified data layer — changes this fundamentally:

• Direct Lake instead of Import: Reports can query data directly from the lakehouse without importing it. Real-time freshness, no duplication, no artificial model size limits.
• Shortcuts & Mirroring: Connect external data sources — Snowflake, SQL Server, Azure SQL — without copying data. The data stays where it lives; Fabric provides a unified access layer.
• No more 8-refreshes-per-day limit: With Direct Lake, your reports always reflect the latest data. No scheduling gymnastics, no “the data is from this morning” disclaimers.
• Break the 1 GB barrier: Large datasets that previously required Premium capacity or complex workarounds now have room to breathe.
• Cross-team collaboration: Different departments share data through Lakehouses and Shortcuts instead of building isolated silos. Finance can access the same data foundation as Operations — governed, consistent, up-to-date.

In aviation terms: Instead of every plane carrying its own cargo hold, you now have a central logistics hub. Every flight can access what it needs, when it needs it — whether the cargo originated locally or was shipped in from an external partner.

4. The Control Tower — Monitoring & Governance

The control tower sees everything: performance, lineage, impact, security

A small regional airport has one person with binoculars, a radio, and a weather app. It works — until traffic grows. Then you need a proper control tower with radar, flight tracking, and a full operations team.

That’s the difference between Power BI without Fabric and with it.

Without Fabric, a user reports: “My report shows an error.” Your options? Basically none. No logs, no query history, no details. You can’t reproduce it, you can’t trace it, you can’t help — unless the error happens to occur again right in front of you.

With Fabric, you get the full control tower:

• Workspace Monitoring: Every query, every error, every performance spike — logged and traceable. A user reports a problem from yesterday? You look it up, see the exact DAX query, the filter context, and what went wrong. Retrospective analysis becomes possible.
• Automated quality checks: Scan all reports and semantic models for rule violations, performance issues, and configuration problems — continuously, not just when someone remembers to check.
• Lineage & Impact Analysis: Before changing a data source, a column, or a measure — see exactly which reports and dashboards are affected. No more “we didn’t know that report depended on this table.”
• OneLake Security: One unified security model across all data. Define access rules once; they apply everywhere — across Lakehouses, Warehouses, and Semantic Models.

In aviation terms: Your airport now has radar, flight tracking, runway management, and air traffic control — all in one tower. No more flying blind.

5. AI-Ready — The Data Foundation

AI is no longer a future project — but without the right data foundation, every initiative remains patchwork

What does it mean when an airplane is “ready”?

It depends on who you ask:

• The pilot says: preflight checks are done
• Maintenance says: the plane is repaired and certified
• Operations says: the plane is assigned to a flight
• The CEO says: the plane is in our fleet

Same plane — four different meanings of “ready.” Without a shared understanding, communication breaks down.

That’s exactly the challenge with data. What does “revenue” mean? Ask Sales, Finance, and Operations — you’ll get three different answers.

This is where Ontology comes in: a shared understanding of your business — for humans AND for AI. Your semantic models become that ontology. Everyone speaks the same data language.

Fabric makes your data AI-ready from day one:

• Central Data Lake for ML/AI: All data in OneLake, immediately available for Machine Learning and AI models. No complex data preparation, no separate pipelines. Data that powers your reports today can train models tomorrow.
• Semantic Layer as Ontology: Your semantic models define what business terms mean. That shared understanding is what makes AI responses accurate and trustworthy.
• Open Standards: Data in OneLake is stored as Delta-Parquet. Any ML framework — Python, Spark, R — can access it directly. No vendor lock-in, no format conversions.

This is perhaps the most future-critical argument: organizations that don’t centralize their data now will struggle to leverage AI later. Fabric doesn’t force you into AI workloads — but it ensures the foundation is there when you’re ready.

In aviation terms: You’re not just building runways for today’s aircraft. You’re laying the foundation — fuel systems, navigation infrastructure, clearance protocols — for the next generation of autonomous, intelligent flight.

6. AI-Ready — Copilot & Data Agents

The co-pilot is ready: AI-assisted analytics for everyone on board

Every pilot has a co-pilot. So should you.

The data foundation is in place. Now comes the part your business teams will love.

• Copilot Built Right In: In Power BI and Fabric Notebooks, analyze data and create reports using natural language. No DAX or SQL required. Available starting from F2 capacity.
• Data Agents: One agent that speaks all the languages: DAX, SQL, GraphQL — you don’t need to know which one. Ask a question, the agent figures out the right query language behind the scenes.
• Reuse Everywhere: Build a Data Agent once, reuse it across Fabric, Foundry IQ, Microsoft 365 Copilot, and any MCP-compatible tool. An MCP endpoint is created automatically with each agent. Zero extra setup.
• Custom Instructions at Every Level: Want the agent to respond in Chinese? Set it in the agent instructions. But it gets even better: each connected data source can have its own instructions — business context, naming conventions, query hints. Global behavior + source-level precision.
• From Question to Insight in Seconds: Instead of waiting weeks for a new report, users interact with data directly. The semantic model becomes the central knowledge layer — not just for reports, but for AI-powered analytics.

In aviation terms: Your airport now has a co-pilot in every cockpit. Not replacing the pilot — but augmenting their capabilities, handling routine tasks, and making the entire operation smarter.

7. Fabric Grows with You

Start small, scale intentionally — Fabric grows with your ambitions

The last point might be the most important one: Fabric doesn’t ask you to go big on day one.

Here’s what surprises many people: even the smallest Fabric capacity — an F2 — already unlocks the full feature set. Deployment Pipelines, Git Integration, Workspace Monitoring, Direct Lake, Copilot, Data Agents — all available. No Premium Per User licenses needed. No feature gating. Everything from the previous six sections works on the smallest SKU.

That changes the adoption conversation entirely. You don’t need executive sponsorship for a large capacity commitment. Start with an F2 or F4. Pick one workspace, one high-value use case. Let your team experience the difference. Then, as value becomes visible, scale intentionally:

• Add more workspaces to the capacity
• Enable Direct Lake for high-traffic reports
• Introduce Notebooks for automation
• Onboard Data Engineers, Data Scientists, Real-Time Engineers onto the same platform
• Cover all use cases — ETL, Notebooks, Planning, Warehouses, Lakehouses — and reduce shadow IT

In many cases, a small F-series capacity is even cheaper per user than adding PPU licenses once you have more than a small group of users. Fabric is not a niche solution — it’s a single platform for all data consumers. All use cases covered — ETL pipelines, Notebooks, Warehouses, Lakehouses, Eventstreams, Planning — all in one ecosystem. That means less shadow IT, more control, and a future-proof architecture that evolves with every Fabric update.

This article complements my earlier deep-dive: Power BI Without Fabric Is Like Owning a Sports Car but Leaving It in Eco Mode. That article goes into technical detail on BPA, Vertipaq Analyzer, Workspace Monitoring, and Premium feature access. This article tells the story from 10,000 feet — the altitude where the bigger picture becomes clear.

If you manage a Microsoft Fabric capacity, there’s a good chance your users have already experienced throttling — 20-second delays, rejected queries, or broken dashboards — without you even knowing. The root cause is usually a temporary CU spike that pushes the capacity past its limits. The fix? Capacity Overage — a zero-cost insurance policy that automatically absorbs those spikes before they impact users.

In this article, I’ll explain what happens without overage, how to enable it, and how to combine it with Surge Protection for comprehensive capacity resilience.

The Problem: What Happens Without Overage

Fabric uses a smoothing mechanism to spread compute (CU) consumption over time. When usage exceeds what the capacity can handle, throttling kicks in — and it gets progressively worse:

• 20-second delays on every interactive request. When smoothed usage exceeds 10 minutes of future capacity, Fabric adds a 20-second wait to every dashboard query, report load, and ad-hoc analysis. Users notice immediately.
• Full rejection of interactive workloads. Once the 60-minute threshold is breached, all interactive requests — report views, DAX queries, dataflow previews — are rejected outright. Users see error messages instead of data.
• Background jobs blocked for up to 36+ hours. At the 24-hour threshold, even scheduled refreshes, pipelines, and Spark jobs are rejected. Recovery can take 1.5× the overload window — meaning a capacity at 250% background rejection needs ~36 hours to recover, during which nothing runs.
• Cascading user frustration & lost trust. End users don’t see “CU exhaustion” — they see broken dashboards, failed refreshes, and unresponsive reports. Repeated incidents erode confidence in the platform and drive shadow IT.

The Solution: How Capacity Overage Helps

• Automatic throttling prevention. Overage kicks in the moment the interactive delay threshold (>100%) is crossed. It pays off excess CU debt so delays and rejections never reach the user.
• Zero standing cost. There is no charge for having overage enabled. You only pay when it actually activates — and only for the CU-hours that would have caused throttling.
• Admin-controlled spending limit. Set a rolling 24-hour CU-hour cap (in multiples of 48 CU). Once the limit is reached, standard throttling resumes — so costs are always predictable and bounded.
• Instant activation, no restart required. Overage becomes active within 5 minutes of enabling. No capacity pause/resume, no workspace migration. Toggle it on and it works.
• Works alongside Surge Protection. Overage handles interactive spikes; Surge Protection limits background job accumulation. Together they provide comprehensive capacity resilience.

Cost Perspective: Overage vs. Scaling Up

Overage charges at 3× the pay-as-you-go rate, but only for excess CU-hours actually consumed. For occasional spikes this is significantly cheaper than permanently over-provisioning by upgrading to the next SKU.

Rule of thumb: Keep the overage limit at ⅓ of your daily CU-hours — that is the break-even point with scaling up to the next SKU size.

When to Use — and When Not

• Ideal for: Rare unexpected spikes, small routine overloads, business-critical dashboards that cannot tolerate delays, capacities shared across multiple teams.
• Not a substitute for: Persistent under-sizing (scale up instead), workload optimization, or dedicated capacity isolation for mission-critical workloads.

Surge Protection: Prevent Runaway Background Jobs

Surge Protection is a complementary capacity setting with two controls:

• Workspace Consumption (interactive + background): Set a per-workspace CU limit as a percentage of total capacity over a rolling 24-hour window. When a workspace exceeds the threshold, it is blocked and all operations are rejected. Each workspace can be tagged as:
  • Available (default): follows surge protection rules
  • Mission Critical: exempt from workspace-level blocking, keeps running during spikes
  • Blocked: all operations rejected (manual or automatic)
• Background Operations (background only): Set a background rejection threshold (e.g., 60%) so background jobs are rejected before the capacity enters deep throttling (normally at 100%). This frees up CU for interactive use and prevents long recovery times. Does not directly protect interactive requests.

Combined Strategy: Surge Protection + Overage

You can combine both features on a single capacity to protect specific workspaces from each other — for example, a development workspace from a production one, both on the same capacity:

1. Enable workspace-level surge protection with a CU % threshold per workspace.
2. Mark your critical workspaces as Mission Critical — they are exempt from workspace-level blocking.
3. Leave other workspaces as Available — they get auto-blocked before causing capacity-wide throttling.
4. Enable Capacity Overage — catches remaining interactive spikes for your mission-critical workspaces.

Result: Non-critical workspaces get blocked by surge protection before they can cause overage billing. Overage effectively only fires for mission-critical workspaces. Surge protection reduces overage activation frequency, keeping costs low.

Note: Capacity-level throttling still applies to all workspaces once CU limits are fully exhausted. Mission Critical status only overrides workspace-level surge protection, not capacity-level limits. Overage handles that gap.

Recommendation & How to Enable

Enable Capacity Overage on every production F16+ capacity with a conservative spending limit (⅓ of daily CU-hours). This provides a zero-cost insurance policy when idle and an automatic safety net when spikes occur — protecting user experience without requiring admin intervention.

1. Admin Portal → Capacity Settings → select your capacity
2. Expand “Capacity Overage” → toggle On
3. Set a 24h CU-hour spending limit (start conservative, e.g. 48–96 CU-hours)
4. Click Apply — active within 5 minutes
5. Monitor via Capacity Metrics app + Azure Cost Management