> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Campaign cost controls walkthrough > Set a per-campaign hard spending cap, a send-rate throttle, and a business-hours-only switch; understand auto-pause and recovery, the default pace and per-channel ceiling, and how the three time gates precedence. # Campaign cost controls walkthrough Every campaign carries three operator controls for spend and timing: a hard spending cap, a send-rate throttle, and a business-hours-only switch. You set them while composing the campaign, and the Review step shows each one again as a summary card before you launch. This guide explains what each control does at send time and how it layers with the other spend controls on your account. ## 1. Three layers of spend control Orbit measures your sending against three independent budgets. They differ in scope, and they compose: each one only sees the spend in its own scope, and the strictest applicable control wins. | Control | Scope | Where you set it | Use it for | | - | - | - | - | | Org wallet spend cap | Every outbound send in the organization | Billing → Alerts ([console walkthrough](https://docs.orbit.devotel.io/guides/spend-cap-console.md), [field reference](https://docs.orbit.devotel.io/billing/spend-caps.md)) | A monthly ceiling on total spend; the last line of defense | | Per-campaign hard cap | One campaign's sends | The campaign wizard (`credit_cap_usd_cents` over the API) | A promotion or blast whose budget you know up front | | Per-key usage budget | One API key's usage | [Usage budgets and alerts](https://docs.orbit.devotel.io/guides/api-key-usage-budget-alerts.md) | Isolating spend per integration, team, or environment | The org cap is the only control that aggregates across campaigns: it reads month-to-date spend from your wallet and can notify, pause, or block outbound when a threshold rule trips. The per-campaign cap never sees spend from other campaigns, and a per-key budget never sees what your other keys send. Layer them in practice: per-key budgets for isolation, per-campaign caps for campaign budgets, and the org cap as the ceiling over everything. ## 2. The per-campaign hard cap: semantics, auto-pause, recovery Set the cap as an amount in your organization's currency while composing the campaign; the same value is `credit_cap_usd_cents` if you create campaigns over the API. The Review step's **Hard spending cap** card shows the amount, or **No limit** when unset. No limit is the default: until you set a cap, the campaign spends freely up to whatever org-level controls you have. When recorded spend on the campaign reaches the cap: * The platform auto-pauses the campaign and stops dispatching the remaining audience. * Recipients who were not yet sent to simply receive nothing. Nothing errors on their side, and replies from recipients already sent keep routing to your inbox as usual. * The campaign shows as paused, distinct from a draft or a completed send. **Recovery.** Edit the campaign to raise or remove the cap, then resume the send. Removing the cap returns the card to **No limit**; raising it gives the remaining audience the headroom between the old and new amount. **Recurring campaigns.** Each scheduled occurrence starts its spend accounting at zero under the same cap. The cap therefore bounds one occurrence, not the running sum of the recurrence, and an occurrence that paused at the cap does not cancel the schedule. If the recurrence as a whole needs a ceiling, put one at the org level: a monthly budget plus a threshold rule in [Spend caps on the dashboard](https://docs.orbit.devotel.io/guides/spend-cap-console.md). ## 3. Throttle: manual ceiling, default pace, per-channel ceiling The throttle caps how fast the campaign dispatches, in messages per second. Leave it unset and the campaign dispatches at the platform's carrier-friendly default pace of 50 messages per second; the Review step labels the rate "(default)" so you can tell the default from a rate you chose. Unset is a default, not unlimited. Two ceilings apply on top of whatever you type: * **Per-channel ceiling.** Each channel has a real carrier-side throughput ceiling, and Orbit clamps dispatch to it. Typing a throttle above the channel's ceiling does not dispatch faster. * **Adaptive pacing.** With [adaptive pacing](https://docs.orbit.devotel.io/guides/adaptive-pacing.md) on, the platform tunes the effective pace inside your ceiling from live delivery signals, trading speed for deliverability when a route degrades. Set a manual throttle when a carrier assigns you a known throughput. US 10DLC brands carry an assigned messages-per-second rate; keep the throttle at or under it so sends do not queue into carrier-side filtering ([10DLC throughput planning](https://docs.orbit.devotel.io/guides/10dlc-carrier-assigned-throughput-planning.md)). The Review step's estimated delivery time honors your throttle when set and falls back to the 50 msg/s default pace otherwise, so the estimate stays honest either way. ## 4. Three time gates: business hours, quiet hours, TCPA Three distinct gates decide when a queued message may actually dispatch. A send fires only when every applicable gate allows it, so the effective window is the intersection of all three. 1. **Business hours only** (per campaign). The switch restricts dispatch to 9 AM to 5 PM recipient local time; the Review card reads "Delivers 9 AM – 5 PM recipient local time" when on. Sends that fall outside the window wait for the next business window. 2. **Quiet hours** (org and per campaign). Configured no-send windows you define, typically overnight; see [per-campaign quiet hours](https://docs.orbit.devotel.io/guides/per-campaign-quiet-hours.md). 3. **TCPA window** (legal floor). For voice and SMS to US numbers, the federal 8 AM to 9 PM recipient-local window. The platform enforces it server-side and defers out-of-window sends rather than failing them; see [send gating and quiet hours](https://docs.orbit.devotel.io/concepts/send-gating-and-quiet-hours.md). Precedence: TCPA is the floor and no setting widens it. Quiet hours and business hours only narrow inside it. Because the 9-to-5 business window sits inside the 8-to-9 TCPA window, turning the switch on makes the business window the effective one; quiet hours can still carve further inside it. ## 5. Worked example: flash sale with cap, throttle, and fallback A 40,000-contact flash sale, SMS primary with email fallback, \$600 budget: * **Cap.** Set the hard cap to \$600, the promotion's whole budget. If spend reaches it mid-send, the campaign pauses instead of overrunning; unsent contacts simply are not sent this round. * **Throttle.** Your 10DLC brand's assigned throughput is the ceiling that matters; set the throttle just under it, 40 msg/s in this example. 40,000 contacts at 40 msg/s dispatches in roughly 17 minutes, which the Review step's delivery estimate confirms before launch. * **Fallback chain.** Recipients whose SMS fails delivery advance to the email leg of the chain after its wait ([fallback chains](https://docs.orbit.devotel.io/guides/fallback-chains.md)). Fallback sends are campaign sends, so they count against the \$600 cap like the SMS leg does; size the cap for the chain, not just the primary channel. * **Time gates.** The sale goes out at 9 AM. With business hours only on, nothing lands before 9 AM or after 5 PM recipient local even though TCPA would allow 8 AM; the business window is the narrower gate and wins. Before applying this shape to a peak-season send, rehearse it against your real volumes in [peak season capacity rehearsal](https://docs.orbit.devotel.io/guides/peak-season-capacity-rehearsal.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.