Lesson 8 of 8 · 10 min
A Capacity Operating Model
Capacities rarely become expensive in one decision. They drift. A new workspace here, a more frequent refresh there, a notebook nobody stopped, a guardrail someone turned off during an incident and never turned back on. Six months later the capacity is a size larger and nobody can explain why.
The fix is not a better tool. It is an operating model: clear ownership, visible usage, early alerts, a short regular review, and a runbook that survives the people who wrote it.
Ownership
Every capacity needs three named roles. One person can hold more than one.
| Role | Responsible for |
|---|---|
| Capacity owner | The SKU, cost plan, guardrails, and the weekly review |
| Workspace owners | The efficiency of the items in their workspaces |
| Finance partner | Budget, reservation decisions, and chargeback |
Control who can assign workspaces to each capacity. If anyone can attach a workspace to the production capacity, nobody owns what runs on it. Limit capacity contributor permissions to people who will answer for the consumption.
Make usage visible with chargeback
People change behavior when they see their own consumption. The Microsoft Fabric Chargeback app breaks capacity usage down by workspace, item, domain, and user, with daily utilization and drill-through pages.
A few practical points:
- Organize workspaces into domains that match how your organization budgets. Usage that is not assigned to a domain appears as “No domain,” which is a useful list of workspaces without a clear owner.
- The report refreshes daily. It is for allocation and trends, not live monitoring.
- Operations started by a service principal appear under a generic user name, so tag pipelines and automation by workspace rather than relying on the user column.
You do not need to send invoices to start. Showback, sharing each team’s share of the capacity every month, is usually enough to start the right conversations. Move to chargeback when the numbers are trusted.
Alerts before users notice
Waiting for users to report slowness means the capacity is already in trouble. Set up two kinds of alerts.
- Capacity alerts. Capacity overview events in the Real-Time hub stream utilization and state roughly every 30 seconds. An Activator rule can notify the capacity owner when interactive delay stays above a chosen level for several minutes, when surge protection activates, or when overage begins. Alert on sustained conditions, not a single reading.
- Cost alerts. The capacity is an Azure resource, so Azure Cost Management budgets can alert when actual or forecast spend crosses a threshold. Include the capacity overage meter. A budget alerts, it does not stop spending, so pair it with a person who acts.
The weekly review
Fifteen minutes a week prevents most drift. Use the same questions every time:
- Did any throttling chart cross 100%? If yes, is there a completed incident worksheet?
- What are the top five items by CU-seconds, and did any of them change?
- Is the weekday background percentage trending up?
- Did surge protection, overage, or a workspace block activate? Was it expected?
- Did any scheduled resize or pause fail?
- Is OneLake storage growing faster than the business reason for it?
Then once a month, add three more:
- Does the sizing envelope still hold, or has a trigger condition been reached?
- Does reservation coverage still match the working-hours level?
- Has any workspace grown without an owner or a domain?
Write down the answers. A month of short notes is the best defense when someone proposes a larger SKU.
A gate for new workloads
Most capacity surprises arrive as new workloads. Ask three questions before a significant workload goes live on a shared capacity:
- What is the estimated CU demand, using the method from lesson five, and what evidence supports it?
- Which guardrail state should its workspace have: available, mission critical, or isolated?
- Who owns its consumption after launch?
This is not a heavy approval process. It is a short conversation that prevents the most expensive kind of surprise.
Exercise: write the runbook
Put the course on one page per capacity. Keep it where the on-call person can find it.
Capacity: SKU: Region:
Capacity owner: Finance partner:
Purpose and service level:
Baseline (lesson 2):
Weekday background %: Interactive peak %:
Top five items and owners:
Incident response (lesson 3):
Where to confirm throttling:
Emergency levers and who can use them:
Postmortem worksheet location:
Efficiency backlog (lesson 4):
Next three planned fixes:
Sizing envelope (lesson 5):
Expected and high cases:
Trigger to change size:
Guardrails (lesson 6):
Surge protection: Workspace limits:
Mission-critical workspaces: Overage threshold:
Spark on-demand limit:
Cost plan (lesson 7):
Reservation: Scheduled resizes:
Pause schedule: Automation identity:
Operations (lesson 8):
Alerts and recipients:
Weekly review owner and time:
Chargeback or showback cadence:If a field is empty, you have found the next thing to work on.
Where to go from here
You now have the full loop: understand how capacity bills, read the evidence, diagnose by shape, make the work cheaper, size with a range, protect critical work, match cost to usage, and keep it owned.
The capacity is not the product. It is the shared engine underneath everything your data platform does. Running it on evidence is what lets the rest of the platform grow without the bill becoming the story.