Team spend caps and admission
Block new estimated commitments without treating delayed metering as a precise invoice ceiling.
Spend admission rejects new resource commitments when a configured team or project cap would be exceeded. Budget alerts remain a separate notification feature.
Configure a cap
Open Usage → Spend controls, choose team or project scope, currency, period, amount, and the covered resource classes. Team membership or allocation labels resolve according to the policy's explicit ownership rule.
The preview lists current attribution and resources without an owner. Unassigned usage must follow an explicit fallback policy rather than disappearing from organization accounting.
Admission behavior
A covered create, resize, or reservation checks the policy's current metered usage and estimated new commitment. Rejection identifies the limiting cap and requested increase. It does not terminate existing guests or delete retained backups.
Accepted operations can continue after a cap changes. Retained disks, transfers, late provider adjustments, and usage not covered by admission can continue adding charges. The cap is not a guarantee that the final invoice cannot exceed its configured amount.
Ownership and period boundaries
Moving a resource to another team requires admission and allocation checks. Changing a label cannot bypass the reviewed team scope. Historical attribution and issued invoices remain under their recorded accounting rules.
A new period resets the policy's evaluation interval, not the lifecycle of resources. Existing allocations can consume the new period's estimated commitment before another create request occurs.
Overrides
A temporary exception identifies scope, amount or action, approver, reason, and expiry. It does not remove project quotas or physical capacity requirements. Review unused exceptions after an incident.
Use budget notifications before a hard admission boundary so operators can change planned deployments. See Quota API, usage and billing, and governance exceptions.