OCI Budgets and Alerts: Catching Overruns Early

The budgets service in OCI is free, takes minutes to configure, and is absent or token in a remarkable share of the tenancies we assess. The usual setup is one budget at the tenancy root, threshold at 100 percent, alerting a mailbox nobody reads. That configuration does not catch overruns, it confirms them. This article describes what a working configuration looks like: budgets scoped to the boundaries where spending decisions actually happen, thresholds that fire while there is still time to act, and routing that puts the alert in front of the person who can do something about it. It is part of our wider series on advanced OCI operations, where budget alerting forms the detective control that the preventive controls lean on.

What an OCI budget actually is

A budget in OCI is a monthly spending target attached to a scope, with alert rules that fire when actual or forecast spend crosses a percentage of that target. The scope is the design decision that matters. A budget can watch an entire tenancy, a single compartment together with its children, or every resource carrying a particular cost tracking tag, and those three scopes correspond to three different questions. The tenancy budget asks whether the whole estate is on plan. The compartment budget asks whether a workload or an environment is on plan. The tag based budget asks whether a project, a team, or an initiative is on plan, regardless of where its resources physically sit in the compartment tree.

Budgets reset on a monthly cycle aligned to your billing period, and each can carry multiple alert rules. The two rule types behave very differently in practice. An actual spend rule fires when money already consumed crosses the threshold, which makes it accurate and late. A forecast rule fires when the service projects that month end spend will cross the threshold, based on the run rate so far, which makes it earlier and occasionally wrong. A working configuration uses both, the forecast rule as the early tripwire and the actual rule as the confirmation that the tripwire was real.

Scoping budgets to decision boundaries

The single root budget fails because nobody owns the number it watches. When the tenancy budget alert fires, every team can plausibly assume some other team caused it, and the alert dies in a shared inbox. The fix is structural: scope budgets to the boundaries where a specific person can recognize the spend as theirs and act on it. In a tenancy organized along the lines described in compartment design patterns for growing tenancies, that usually means one budget per top level workload or environment compartment, sized from history rather than hope, plus tag scoped budgets for anything that cuts across the tree, shared platform services, a migration project, a proof of concept with a fixed allowance.

Tag scoped budgets deserve more use than they get. They depend on cost tracking tags being applied consistently, which is exactly the discipline covered in tagging governance on OCI, and they reward that discipline by making spend visible along organizational lines instead of infrastructure lines. A budget on the tag for a delivery team tells that team what they spent this month across every compartment they touch, and a threshold breach lands on the person who ran the workloads, not on a platform team three steps removed from the decision.

Threshold design: the ladder, not the cliff

One threshold at 100 percent is a cliff: silence all month, then an alert that arrives precisely too late. A ladder works better. A forecast rule at 100 percent fires in the first half of the month if the run rate is off plan, when there is still time to stop or resize whatever is burning. An actual rule at 75 percent confirms mid month whether the trajectory is real. An actual rule at 95 percent is the escalation step, the point where the owner should be explaining the number to someone, not discovering it. For volatile workloads, development compartments, anything with autoscaling, widen the rungs and lean on the forecast rule, accepting some early month noise as the price of early warning. For stable production estates, tighten the rungs, because a stable workload drifting past 75 percent of budget mid month is genuinely unusual and worth a look.

Budget size itself should come from the cost reports, not from intuition. Set each budget at the trailing three month average plus the growth you actually expect, then revisit quarterly. A budget set far above real spend never fires and teaches people to ignore the mechanism. A budget set below real spend fires constantly and teaches them the same thing faster. The mechanism only works while its alerts are rare enough to mean something.

Routing: getting the alert to someone who can act

Budget alerts deliver to email addresses configured on the rule, which is where most setups stop and most value leaks away. Email is acceptable for the executive tier, but action tier alerts should flow into the channels where the owning team already works. The standard pattern routes the alert through a Notifications topic, and from the topic onward to whatever the team watches: a chat webhook, an incident tool, or a Function that enriches the alert before passing it on. The enrichment step is worth the small build: a raw budget alert says a threshold was crossed, while an enriched one can attach the top cost movers in the affected scope from the usage data, turning a number into a lead. Teams act on leads.

For a small class of scopes, the right response is automation rather than conversation. A proof of concept compartment with a hard allowance can pair its budget alert with a Function that stops compute instances when the actual rule at 100 percent fires. We use that pattern sparingly, stopping resources automatically in production is a way to convert a cost incident into an availability incident, but for sandboxes and trials it converts the budget from advisory to enforced, and it pairs naturally with the scheduled shutdown patterns described in stopping idle compute on a clock.

What budgets cannot see

Three blind spots are worth designing around rather than discovering. First, lag: cost data behind budgets is not real time, and consumption typically takes several hours to a day to appear, so a budget alert is an early warning system on the scale of days, not a circuit breaker on the scale of minutes. Anything that can do serious financial damage in hours, a runaway GPU job, a misconfigured data transfer loop, needs Monitoring alarms on usage metrics as the fast tripwire in front of the budget. Second, commitments: budgets track consumption against the monthly target, but tenancies on Universal Credits also need to track drawdown against the annual commit, including the support and licensing arithmetic that sits outside the budgets service entirely. Third, attribution gaps: untagged resources and shared services consume real money that tag scoped budgets cannot see, which is why budget design and the allocation discipline described in cost allocation on OCI have to ship together. The compartment budgets catch what the tag budgets miss, and the monthly reconciliation catches what both miss.

Rolling out budgets in seven steps

The metric that proves it works

One number tells you whether this machinery earns its keep: time to detection, the gap between the day an overrun began and the day a human acknowledged an alert about it. At invoice driven estates that number is 30 to 45 days. A tuned budget configuration brings it under three, and the fast tripwire alarms bring the dangerous subset under one. Track it for every overrun above a materiality line you choose, and trend it quarterly alongside a second number, alert precision, the share of fired alerts that pointed at something real. Detection time falling while precision holds is the signature of a configuration that is working. Precision falling is the early sign of alert fatigue, and the correct response is pruning thresholds, not adding more.

Where budgets fit in the larger cost discipline

Budgets and alerts are the detective layer of OCI cost management, and they are only one layer. Beneath them sit the preventive controls, quotas that cap what can be provisioned in the first place, covered in service limits and quotas on OCI, and the scheduling that stops paying for compute outside working hours. Above them sits the corrective layer, the rightsizing and architectural work where the real money lives. In our optimization engagements, the estates that find the typical 40 percent reduction are rarely the ones missing alerts. They are the ones missing the follow through, alerts that fired into inboxes for months while the spend pattern that triggered them was never investigated. The budget catches the symptom. Someone still has to treat the cause, which is the work our OCI optimization service exists for, on a fee paid only out of verified savings. Across 500+ OCI engagements, the pattern holds: the cheapest overrun is the one caught in week one, and week one detection is a configuration choice available to any tenancy, this week, for free.