At the end of Part 4, the Tuesday-morning story finally had a shape. The team stopped saying “Fabric is slow” and started saying something far more useful: “Our refresh schedule is colliding with finance’s reporting window, and here’s what we’re changing.”
That second half of the sentence is where most organizations get stuck. Knowing which job caused the slowdown, and whose it is, is real progress. But visibility on its own doesn’t fix anything. Without a plan for what to do with it, you just watch the same spike happen every Monday, with better charts.
This post is that plan: four steps, in order. You’ve seen pieces of each one across this series. Here’s how they fit together into a sequence you can start applying this week.
The playbook at a glance
- Establish a capacity baseline. Know what normal looks like before you change anything.
- Organize workloads intentionally. Decide what shares capacity, and protect what matters most.
- Apply the right cost and workload controls. Try the cheapest fix first. Resizing comes last.
- Create accountability. Give every major workload an owner and a regular review.
If you’ve been following the series, none of these steps should feel like a surprise.
- Step 1 puts the six monitoring questions from Part 4 to work.
- Step 2 is Decision 2 from Part 2, turned into action.
- Step 3 relies on the smoothing and throttling mechanics from Part 3.
That’s deliberate. The playbook isn’t a new set of ideas. It’s the order in which to act on the ones you already have.
Step 1: Establish a capacity baseline
A capacity baseline is a clear picture of what normal consumption looks like for your environment, by workspace and by workload, before you change anything.
It’s tempting to skip this step, especially in the middle of an incident. Don’t. Without a baseline, every spike feels like an emergency, and every fix is a guess. With one, you can tell the difference between a Monday that’s unusually bad and a Monday that’s bad every week.
A useful baseline answers a few things:
- Who consumes the most? Which workspaces and items account for the bulk of your capacity use.
- What’s recurring, and what’s a one-off? A pattern that returns every week is a planning problem. A single spike is an incident.
- When do users actually feel it? Performance and refresh complaints matter more than any single metric moving.
Then take one more step that’s easy to overlook: line your capacity behavior up against the business calendar. Month-end close, product launches, seasonal reporting cycles, the Monday morning refresh wave. When capacity behavior maps to real business events, it stops feeling random, and you can plan for it instead of reacting to it.
The baseline tells you where the pressure is. The next step decides where that pressure is allowed to land.
Step 2: Organize workloads intentionally
In Part 2, we made the case that if you don’t decide what shares capacity, Fabric effectively decides for you: everything shares. Step 2 is where you make that decision on purpose.
The options haven’t changed. You can separate dev and test from production, divide capacity by business domain, split by workload type, or give newer AI workloads their own lane. (Part 2 covers the trade-offs of each split in detail.)
What the baseline adds is priority. Start with the move that matters most: protect your high-value interactive workloads from heavy background activity. These are the dashboards and reports leadership actually opens every morning. If Step 1 showed them absorbing the aftermath of someone else’s overnight refresh, you’re looking at the Tuesday-morning echo from Part 3, and an intentional boundary is often the cleanest fix.
A caution in the other direction: the answer to “everything shares” is not twenty tiny capacities. Over-fragmenting creates its own administrative burden and strands compute in pools that don’t need it. Aim for a small number of boundaries, drawn around the workloads that genuinely need protecting.
Step 3: Apply the right cost and workload controls
This is the step most teams want to jump to first, and it’s the one where order matters most.
Start with the cheapest fixes
Throughout this series, we’ve recommended the same sequence:
Optimize → Reschedule → Isolate → Resize
- Optimize the workload if it consumes far more than it should, even when it runs alone.
- Reschedule background work if it collides with busy interactive hours.
- Isolate critical workloads if they keep absorbing the impact of other teams’ jobs.
- Resize the capacity only when utilization stays high around the clock after the first three are ruled out.
The first two usually cost nothing but time. The third costs a boundary. The fourth shows up on your bill every month from then on. That’s why resizing belongs at the end of the list, not the top.
Then reach for the precision tools
Fabric also offers newer levers built for specific situations. Each one is useful. None of them is a strategy on its own.
The pattern across all three is the same. These are precision tools for specific problems, not a blanket strategy. Autoscale Billing can take a noisy neighbor off your shared pool, but you pay for Spark differently. Surge protection can keep a runaway job from taking down everyone else. Overage can buy you time during an incident. But reaching for any of them before you’ve worked through the order of operations usually means paying a premium for a problem that a schedule change would have solved.
Step 4: Create accountability
The first three steps fix today’s problem. Step 4 is what keeps it from coming back.
- Start with ownership. Every major workspace and workload should have a named owner: ideally both a business owner who can speak to its value and a technical owner who can speak to its consumption. When the next backlog hits, “whose job caused this?” should have an immediate answer.
- Next, give those owners visibility into what they consume. As we covered in Part 2, you don’t need full chargeback on day one. Showback, simply making consumption visible to the team that creates it, is a perfectly good starting point, and it delivers most of the behavioral benefit. Once people can see their own number, behavior changes.
- Finally, and this is the piece most organizations miss: review capacity on a regular rhythm, not just after something breaks. A common pattern we see is a monthly consumption review with workload owners and a quarterly look at sizing and boundaries.
In Part 4, we suggested that teams with strong visibility should turn it into “a regular operating rhythm rather than an incident-response tool.” This is what that looks like in practice. The organizations that struggle most with Fabric costs are the ones that only look after a throttling incident or a surprise bill. The ones that succeed treat capacity like any other part of the business they manage on purpose.
Where to start this week
You don’t have to do all four steps at once. Here’s one concrete first move for each:
- Baseline: Pull recent consumption from the Capacity Metrics App by workspace and item, flag your top five consumers, and mark each spike as recurring or one-time.
- Organize: List the reports leadership relies on daily and check which background jobs share their capacity and their hours.
- Control: Take your biggest recurring issue and work through optimize, reschedule, isolate, and resize, in that order, before you touch the SKU.
- Accountability: Name a business owner and a technical owner for each major workspace and put a recurring capacity review on the calendar.
Download the Four-Step Fabric FinOps Playbook one-pager →
The goal was never the smallest bill
It’s worth ending where the webinar did. Fabric FinOps isn’t about driving spend as low as it will go. The goal is matching spend to value while protecting the workloads your business depends on.
The four steps are how you get there: know what normal looks like, decide what shares, fix problems in the right order, and make someone accountable for keeping it that way.
Not sure which step your team is on? A Fabric Capacity Health Check works through all four for your environment and tells you which to prioritize first.
Next in the series: Three Fabric situations you’ll probably recognize: the pilot that slows down in production, the AI workload that changes your capacity profile, and the throttling incident that outlives the spike. We’ll walk through what we’d look at first, and what we’d do, in each one.
Watch the full webinar: Control Microsoft Fabric Costs: A FinOps Playbook for Capacity and Throttling is available on demand now.
Not sure where your capacity stands?
Lantern’s Fabric Capacity Health Check identifies what’s driving your consumption, where performance or cost risk is emerging, and which actions to prioritize first.
