Service Limits and Quotas on OCI: Managing Headroom

Two mechanisms govern what can be provisioned in an OCI tenancy, and they are routinely confused because the console shows them in similar clothes. Service limits are ceilings Oracle sets on your tenancy: how many OCPUs of a given shape family, how many block volume terabytes, how many load balancers a region will let you create. Compartment quotas are ceilings you set on yourselves: policy statements that cap what a compartment may consume, regardless of what the tenancy as a whole is entitled to. One is a wall you negotiate with Oracle, the other is a wall you build on purpose. A mature estate manages both, in opposite directions, pushing limits up ahead of need and pulling quotas down to match intent. This piece covers both disciplines, and sits inside our wider guide to advanced OCI operations.

Service limits: the walls Oracle sets

Every limit is scoped, some per region, some per availability domain, some tenancy wide, and that scoping matters more than the headline number. A compute limit that looks comfortable at region level can still refuse a launch in the one availability domain where your cluster needs to grow. Limits also vary by lifecycle: new tenancies start with deliberately conservative defaults, trial conversions carry trial sized limits into production, and shape families you have never used start near zero. The practical consequence is that a tenancy's limits reflect its history, not its plans, and any significant change of plan, a new workload, a new region, a new shape family, should trigger a limits review before it triggers a provisioning attempt.

The console's limits page, and the corresponding API, reports three numbers per limit: the ceiling, current usage, and what remains. The remaining number is your headroom, and headroom is the quantity this entire discipline manages. The failure mode is never that a limit exists, it is that nobody was watching the gap close, through organic growth, through a migration wave landing, through an autoscaling policy quietly consuming what the next project assumed was available.

Quotas: the walls you build on purpose

Compartment quotas invert the relationship. Written as policy statements, set, unset, and zero, they cap what a compartment can consume: zero GPU OCPUs in development, a modest block volume ceiling in every sandbox, no bare metal shapes outside the compartment that runs them deliberately. Where budgets alert after money is spent, the preventive sibling discussed in OCI budgets and alerts, quotas refuse the provisioning before it happens. They are the difference between noticing the expensive mistake and making it impossible.

Good quota design follows the compartment tree, which is one more reason the hierarchy described in compartment design patterns for growing tenancies pays compound interest. Sandboxes get tight quotas and no exceptions. Development and test get quotas sized to their real historical consumption plus modest slack. Production gets few or no quotas, because the last thing a 2 a.m. scaling event needs is a self inflicted wall, and the controls that matter there are limits headroom and change discipline instead. The asymmetry is deliberate: quotas exist to stop accidents, and accidents concentrate where experimentation lives.

The increase request, treated as a supply chain

Limit increases are requested through the console and fulfilled by Oracle on timescales that vary enormously by resource. Commodity increases, standard compute families, block storage, often clear in hours. Constrained resources behave differently: GPU shapes, large bare metal configurations, dense Exadata infrastructure, and anything in a capacity tight region can take days or weeks, and occasionally the honest answer is that the region needs hardware. The operational consequence is simple: treat limit increases as procurement with lead times, not as a button. Any project plan that lands new workloads should carry a limits line item at least one phase ahead of the capacity actually being needed, and migration wave planning should file increases for the next wave while the current one is still in flight.

Two practices improve outcomes measurably. First, request with justification: increases backed by a concrete consumption plan clear faster and at higher numbers than speculative round figures. Second, request asymmetrically: production and DR regions get generous headroom, sandboxes get none, because every point of unused entitlement in a governed compartment is headroom the platform team does not have to police with quotas.

Headroom for the day everything fails over

The least examined limits in most tenancies are the ones in the disaster recovery region. Active estates consume against their primary region's limits continuously, so the gaps get noticed. The standby region's limits are consulted exactly once, during setup, and then drift out of correspondence with the primary as the estate grows. The day a real failover arrives, the standby region is asked to provision, in an hour, everything the primary grew into over two years, and limits that were right at setup refuse half of it. The fix is a standing rule: every quarterly capacity review reconciles standby region limits against current primary consumption plus growth, and every DR test includes at least one provisioning exercise that would fail if limits had drifted. Estates using capacity reservations for the critical core of the failover footprint take the question off the table entirely for those resources, a tradeoff covered properly in capacity planning on OCI.

Monitoring the gap before it closes

Headroom belongs in the monitoring stack, not in a quarterly spreadsheet. The limits API exposes ceiling and usage per limit per scope, which makes the check scriptable: a scheduled job walks the limits that matter, computes remaining headroom as a percentage, and raises an alert when any falls below a threshold, 20 percent is a sensible default, tighter for slow to increase resources like GPU and Exadata, looser for commodity ones. The alert should open a ticket that results in an increase request, closing the loop from detection to procurement without waiting for a human to feel curious. A fleet level view also catches the second order problem single alerts miss: ten compartments each comfortably inside quota can still sum to a tenancy nearing its regional limit, and only the aggregated view sees it coming.

A six step working practice

When the wall moves at the wrong time

Two edge cases deserve a place in the runbook library. The first is the launch that fails despite available limits, because the availability domain is genuinely short of the requested shape at that moment. Capacity errors and limit errors return different signals, and the responses differ: a limit error means file an increase, a capacity error means try another availability domain or fault domain, fall back to a flexible shape sized equivalently, or use a capacity reservation next time. Conflating the two wastes the first hour of an incident. The second is the quota collision during an emergency change, the forgotten sandbox quota that blocks a legitimate scale up when a workload was moved compartments months earlier. The mitigation is the review calendar above, plus a documented break glass path for editing quota policy fast, with the same change record discipline as any other emergency change.

Owning the walls

None of this is difficult. All of it is forgettable, which is why limits surprises remain a steady source of avoidable incidents in otherwise well run estates. The discipline is a standing rota item: an automated check that never sleeps, a quarterly reconciliation that includes the DR region, and increase requests filed ahead of every project that changes the estate's shape. This is precisely the kind of work a managed operations arrangement absorbs without ceremony. Our OCI managed services practice runs limits and quota governance as part of the standing operations calendar, with 24/7/365 coverage for the moments when the wall turns up mid incident, drawing on patterns from 500+ OCI engagements and 20+ years of combined Oracle experience. The estates that never hit the wall are not lucky. Someone is watching the gap.