Spending Caps and Bill-Shock Protection

Every Orbit project has a spending cap: a hard monthly ceiling on overage charges, defaulting to US$63.16, with email warnings on the way up and a pause instead of an open-ended bill at the top. This guide covers what the cap covers, what happens when it is reached, how to restore a paused site, and the separate build-minute cap that stops a runaway build loop.

What the Cap Covers

The cap applies to usage above your plan's included allowance:

Build-minute overage: US$0.05 per minute beyond your plan's monthly allowance
Bandwidth overage: US$0.03 per GB beyond your plan's monthly allowance

Your plan's base subscription fee is not affected by the cap and is never paused by it.

Traffic from denial-of-service and other malicious volumetric attacks is never billed and never counts towards the cap.

The Default Cap

Every new project starts at US$63.16 per month. You can set it anywhere from US$6.32 to US$6,315.79. There is no "no cap" option, by design.

Find it in Settings, in the Spending cap card. The card shows a progress bar with this month's overage against your cap, and the percentage.

Spending cap card in Orbit project settings

Alerts Before You Hit It

Orbit emails you at 50% and 80% of the cap, once per threshold per billing period. Each email tells you the threshold, the percentage reached, your cap, what you have spent, what is left, and the split between build-minute and bandwidth overage.

The Settings card shows a running warning too. Above 50% it tells you how much headroom is left before a pause; at 100% it warns that serving will pause on the next hourly check.

Alerts go to the account's billing email address. If that address is a shared inbox nobody reads, the pause will be your first notification. Check it is somewhere you will actually see it before you need it.

What Happens At 100%

An hourly check calculates each project's current-month overage against its cap. When it reaches 100%:

Every production environment on the project is set to Paused.
Requests to your site return HTTP 503 with a branded page reading "Site temporarily paused".
The response carries the header X-Orbit-Paused: spending-cap, so uptime monitors can distinguish a pause from an outage.
Kapsule emails you, naming the project, the cap, the build and bandwidth overage, the billing period, and a direct link to the project's Settings.

The check runs hourly, not continuously. Overage can exceed your cap slightly between checks before the pause takes effect. The cap is a spend ceiling with an hour of granularity, not a hard real-time meter.

The pause hits production environments only. Staging and branch previews keep serving. That is deliberate, so a pause does not also block you from testing the fix.

Restoring a Paused Site

Open your project in Orbit.
Open the Settings tab.
Find the Spending cap card, which shows a PAUSED badge and a red panel reading "Site serving is paused".
Enter a higher cap amount.
Click Raise cap & resume.

Serving resumes immediately. No redeploy is needed, and nothing about your deployment changes.

If instead you leave it paused, the hourly check restores serving automatically as soon as overage drops back below your cap, which happens on its own at the start of the next billing period.

Raising the cap raises your maximum possible overage bill for the month. If a site paused unexpectedly, find out why the usage spiked before you raise the ceiling. Look at the project's Analytics tab, which shows this month's build minutes and bandwidth against your plan allowance plus a projected end-of-month figure. A rebuild loop or a hot-linked large asset will simply consume the new headroom too.

Changing the Cap At Any Time

Open the project, then Settings.
Find Spending cap.
Enter a new amount and click Update cap.

The change takes effect immediately for the current billing month. The minimum is US$6.32 and the maximum is US$6,315.79; anything outside that is rejected with a message naming the limit.

If you need more headroom than the maximum allows, contact support rather than looking for a way to disable the cap.

Automatic Reset

Overage usage resets at the start of each billing period, and the alert thresholds reset with it, so you get a fresh 50% and 80% warning each month rather than one warning ever.

If your site was paused at the end of a period, it resumes automatically once the new period begins and usage returns to zero. No action needed.

The Separate Build-Minute Cap

The spending cap limits money. The build spending cap limits build minutes directly, and it is a different control with a different purpose.

Find it in Settings, in the Build spending cap card:

Enter a number of minutes per month, minimum 1. The card converts it to hours as you type, so 120 shows as 2 hours per month.
Click Set cap (or Update cap if one already exists).

Once the monthly total reaches the cap, new builds stop queuing until the next month or until you raise the cap. The card shows a progress bar of minutes used against the cap and warns as you approach it.

Click Remove cap to take it off entirely.

A build cap blocks builds, which means it blocks your ability to deploy a fix. It is the right control for a project you want to protect from an accidental rebuild loop, and the wrong control for a project you deploy to under pressure. If you set one, set it well above your normal monthly usage.

Separately from all of this, every build is aborted at 30 minutes of wall-clock time on every plan. That runaway abort is not configurable and exists so a single hung build cannot consume an entire monthly allowance.

Watching Usage Before It Becomes a Problem

Each project's Analytics tab shows this month's build minutes and bandwidth against your plan allowance, the overage cost so far, and a projected end-of-month figure based on days elapsed.
Orbit, then Usage, shows the account-wide totals.
Each deployment's detail page shows exactly how long that build took and where the time went, phase by phase.

If your projected overage is climbing, look at your build cache hit rate first. On Liftoff and Apex a cache hit removes most of the install phase. The project overview flags a low hit rate for you and explains what it usually means.