Cost SLOs and error budgets for cloud spend

Quick answer

A cost SLO states a target unit cost with a tolerance band, for example cost per thousand API requests below 0.38 USD, measured over a 30-day window. The error budget is the cumulative overspend allowed before action is mandatory, commonly 10 to 15 percent of the target over a quarter. While budget remains, teams ship freely. When it is exhausted, cost work takes priority over feature work until the unit cost returns inside the band. Use unit cost, never absolute spend, so growth does not consume the budget.

Site reliability engineering solved a problem that cost management still struggles with: how to hold a team to a target without either ignoring it or freezing all change. The answer was an objective plus an error budget, and the structure transfers to spend almost unchanged.

Why absolute budgets fail and SLOs do not

A traditional budget says "spend no more than 40,000 USD a month." Traffic doubles, spend rises to 58,000 USD, and the team is over budget despite having become more efficient per unit. The budget conversation becomes about renegotiating the number rather than about efficiency, and eventually everyone learns to pad their request.

A cost SLO says "cost per thousand requests stays below 0.38 USD." Traffic doubling is neutral. Getting less efficient triggers the objective regardless of traffic. That is a far better behavioral signal, and it matches how the business actually thinks about infrastructure.

Defining the objective

Component	Example
Metric	Amortized cost per 1,000 API requests
Target	0.38 USD
Window	Rolling 30 days
Error budget	12% cumulative overspend per quarter
Scope	Production, service-tagged resources plus allocated shared

Set the initial target from the trailing three-month actual, not from an aspiration. If current cost is 0.41 USD per thousand requests, set the target at 0.40 USD, not 0.25 USD. An objective that is breached from day one gets ignored immediately. Tighten it deliberately each quarter, the same way reliability targets are tightened as systems improve.

How the error budget works

Compute the budget as allowed cumulative overspend. With a 0.38 USD target, 60 million requests a quarter, and a 12 percent budget, the quarterly allowance is 60,000 thousand-request units times 0.38 USD times 0.12, which is 2,736 USD of overspend. A month running at 0.42 USD consumes 0.04 USD times 20,000 units, or 800 USD, roughly 29 percent of the budget. Three such months exhaust it.

The policy attached to exhaustion is what makes it real. While budget remains, teams ship normally and nobody reviews sizing decisions. When it is exhausted, cost work moves to the top of the backlog until unit cost is back inside the band, and any change that increases unit cost needs explicit sign-off. That is the same bargain reliability error budgets make: freedom until the number says otherwise.

Choosing the right unit

The denominator must be something the team controls and the business recognizes. API requests for a service, processed jobs for a pipeline, gigabytes ingested for a logging platform, active tenants for a multi-tenant plane, indexed documents for a search system. Avoid revenue as a denominator at team level: individual teams do not control revenue, and a sales quarter would breach or repair the objective for reasons the team cannot influence.

Whatever you pick, the denominator must be measurable from existing telemetry without a special project. If producing the number takes a manual export, the SLO will quietly stop being computed within two months. The unit selection process is covered in unit economics.

Burn rate alerts, not threshold alerts

Borrow the burn rate concept too. Alert when the budget is being consumed fast enough to exhaust it before the window ends, rather than when a static threshold is crossed. A service at 0.39 USD against a 0.38 USD target is barely burning; one at 0.61 USD is burning at roughly 6x and will exhaust a quarterly budget in under two weeks. The second deserves a page, the first deserves a line in the weekly review.

What to do when the budget is gone

Have the response written down in advance so it is not negotiated under pressure. A workable ladder: the owning team investigates and reports the cause within three days, cost work is prioritized above new feature work until unit cost is inside the band, changes that raise unit cost require an engineering manager's sign-off, and if the band is not restored within 30 days the objective is formally renegotiated with an explanation. That last clause matters because sometimes the target really was wrong, and a process with no legitimate way to change the number invites people to ignore it instead.

Keeping unit cost inside the band

Most unit cost regressions arrive through deploys, not through traffic. A new sidecar on every pod, a larger default instance size, a replica added for an experiment that stayed. Pricing infrastructure changes before merge catches those while they are still free to revert. C3X posts the monthly delta on each Terraform change, which lets a team see that a proposed change will move cost per thousand requests from 0.36 USD to 0.44 USD before it consumes half a quarter's error budget.

FAQ

What is a cost SLO?

A stated target for unit cost with a defined measurement window, for example amortized cost per thousand API requests below 0.38 USD over a rolling 30 days. Unlike an absolute budget, it is neutral to growth: doubling traffic does not breach it, but becoming less efficient does. That makes it a behavioral signal about engineering efficiency rather than about business volume.

How does an error budget work for cloud spend?

It is the cumulative overspend allowed before action becomes mandatory, commonly 10 to 15 percent of the target over a quarter. With a 0.38 USD target, 60 million requests per quarter, and a 12 percent budget, the allowance is roughly 2,736 USD. While budget remains, teams ship freely; once exhausted, cost work takes priority until unit cost returns inside the band.

How should the initial cost SLO target be set?

From the trailing three-month actual, not from an aspiration. If current cost is 0.41 USD per thousand requests, set the target at 0.40 USD rather than 0.25 USD, because an objective breached from day one is ignored immediately. Tighten it deliberately each quarter as the system improves, the same way reliability targets are ratcheted over time.

What denominator should a cost SLO use?

Something the team controls and the business recognizes: API requests for a service, processed jobs for a pipeline, ingested gigabytes for a logging platform, active tenants for a multi-tenant plane. Avoid revenue at team level, since teams do not control it. The denominator must be computable from existing telemetry, or the objective will silently stop being measured.

Should cost alerts use thresholds or burn rate?

Burn rate, borrowed from reliability practice. Alert when the budget is being consumed fast enough to exhaust it before the window closes rather than when a static threshold is crossed. A service slightly above target is barely burning and belongs in the weekly review, while one burning at 6x will exhaust a quarterly budget in under two weeks and warrants immediate attention.

What should happen when the cost error budget is exhausted?

Write the response down in advance: the owning team investigates and reports the cause within three days, cost work outranks new feature work until unit cost is back inside the band, changes that raise unit cost need manager sign-off, and if the band is not restored within 30 days the objective is formally renegotiated with an explanation rather than quietly ignored.

What to do next

Catch unit cost regressions before they burn the budget. C3X prices every Terraform change in the pull request. See the quickstart.