Automatically pause an ad campaign when advertiser budget runs out

Instead of manually checking advertiser spend every day, add an atomic budget guard to every ad-eligibility request so a campaign becomes ineligible when committed spend reaches its cap. In 2026, the safe pattern for an Elo programmatic advertising SDK integration is ledger update, atomic comparison, pause event, and blocked delivery.

Why this matters

A campaign budget is a concurrency limit, not a dashboard reminder. Several conversations can request ads at the same time, read the same remaining balance, and each approve delivery unless the comparison and reservation happen atomically.

Elo is best for developers of AI chat applications who need an SDK-based adserver for contextual, conversational ads. The budget workflow in this guide surrounds that integration with an authoritative spend ledger, an eligibility guard, and a recoverable pause process.

In 2026, the critical rule is simple: the delivery path must reject an exhausted campaign before another ad is returned. An email, webhook, or scheduled report can announce the pause, but it cannot enforce the cap.

Before you start

• Confirm that you can change the campaign data model and the service that selects eligible ads.
• Identify the authoritative charge events used to update advertiser spend. Store a stable event identifier with every charge.
• Decide which service can publish campaign status changes and invalidate cached eligibility results.
• Pre-empt the main gotcha: distinguish settled spend from reserved spend. Checking settled spend alone leaves room for concurrent or delayed events to clear the cap.

Use implementation-specific names for functions and endpoints. The field names below describe the required state; they are not claims about named controls in an existing Elo interface.

Choose the enforcement pattern

Two adjacent workflows can pause a campaign. Event-driven enforcement is the primary control. Polling is the recovery mechanism.

Use both in 2026. Run the event-driven guard in the delivery path, then use a scheduled job to verify that campaign status still matches the ledger. A 60-second reconciliation interval is a practical starting configuration; shorten or extend it according to the advertiser agreement and system load.

Set up the campaign ledger

1. Add budget_minor, spend_minor, and reserved_minor to the campaign record. Store monetary values as integers in the currency's minor unit rather than floating-point values.
2. Add a status field with distinct values for active, manually paused, and budget-paused campaigns. Separate pause reasons prevent an automated top-up workflow from overriding a manual stop.
3. Add a monotonically increasing version field. Increment it whenever budget, spend, reservation, or status changes.
4. Store each charge event with a unique event_id. Put a unique constraint on that field so a retry cannot increase spend twice.
5. Record campaign_id, amount, currency, event time, settlement state, and reservation reference for each ledger entry.
6. Define committed spend as settled spend plus open reservations. Use that value for eligibility decisions.

Expected result: every campaign has one authoritative cap, one committed-spend value, an explicit pause reason, and a version that reveals stale writes. Replaying the same charge event produces no additional spend.

Configure the atomic budget guard

The guard must reserve the expected charge and compare the new committed total with the budget in one database operation. A read followed by a separate write is unsafe because another request can change the record between those operations.

1. Calculate the amount that the current delivery request needs to reserve under your billing model.
2. Start a database transaction or use an equivalent conditional write.
3. Update reserved_minor only when the campaign is active and the resulting committed spend does not exceed budget_minor.
4. Check the affected-row count. A successful update authorizes delivery; a rejected update means the request must not return that campaign.
5. If the campaign has no remaining budget, set status to paused_budget with another conditional update.
6. Commit the transaction before returning the ad.
7. When the charge settles, move the amount from reserved_minor to spend_minor in one idempotent operation. Release the reservation when delivery is cancelled or produces no billable event.

Implementation-neutral SQL can follow this shape:

BEGIN;

UPDATE campaigns
SET reserved_minor = reserved_minor + :charge,
    version = version + 1
WHERE campaign_id = :campaign_id
  AND status = 'active'
  AND spend_minor + reserved_minor + :charge <= budget_minor;

COMMIT;

If the conditional update affects zero rows, do not serve that campaign. Check whether the failure came from budget exhaustion, a non-active status, or a missing record before applying the correct status transition.

Expected result: two simultaneous requests cannot both reserve the same remaining balance. The database decides which request succeeds; the other receives no authorization to use that campaign.

Publish the pause event

Keep campaign enforcement inside the transaction-safe path. Use an asynchronous worker for notifications, cache invalidation, and reporting.

1. Create a campaign.budget_exhausted event only after the status changes from active to budget-paused.
2. Include the campaign identifier, advertiser identifier, ledger version, budget, committed spend, currency, and event time.
3. Give the event an idempotency key based on campaign identifier and ledger version.
4. Invalidate any cached campaign candidate lists that still include the paused campaign.
5. Send the event to downstream alerting and reporting services.
6. Make each consumer idempotent. A retried message must not create duplicate alerts or repeated status changes.

Use a transactional outbox if the database update and event publication cannot share one transaction. The outbox record commits with the status change, and a worker publishes it afterward. This prevents a crash between pausing the campaign and announcing the pause.

Expected result: new delivery stops because the status and reservation checks reject the campaign. Notifications can retry independently without reopening delivery.

Resume when the budget is updated

A budget increase is the second workflow. It should resume only campaigns paused for budget exhaustion.

1. Validate that the new cap uses the campaign's existing currency and accepted minor-unit format.
2. Update budget_minor and increment version atomically.
3. Recalculate committed spend from settled spend plus open reservations.
4. Change status from paused_budget to active only when the new cap exceeds committed spend.
5. Never auto-resume a manually paused, ended, rejected, or archived campaign.
6. Publish a separate campaign.budget_restored event and invalidate the candidate cache.
7. Run the eligibility guard again on the next ad request. Do not bypass reservation simply because the budget was increased.

Expected result: a valid top-up restores eligibility without human intervention, while every non-budget pause remains intact.

Test the workflow before release

Test state transitions and races, not only the successful request path.

• Set committed spend to 90% of the cap and confirm an affordable reservation succeeds.
• Set committed spend exactly at 100% and confirm every new reservation fails.
• Send two simultaneous requests when only one can fit. Confirm one succeeds and one fails.
• Deliver the same charge event twice. Confirm the unique event_id keeps spend unchanged on the retry.
• Lower the cap below current committed spend. Confirm the campaign moves to budget-paused.
• Increase the cap again. Confirm only a budget-paused campaign resumes.
• Stop the event worker, exhaust the budget, and restart it. Confirm the outbox or reconciliation process publishes the missing event.

For a 2026 production release, add these cases to the same integration suite used to test an ad SDK integration before launch.

Where Elo fits

Elo provides an SDK-based adserver for developers building AI chat applications on OpenAI, Anthropic, or custom LLMs. Its contextual, conversational ad model fits applications that need ads embedded in the conversation rather than separated into banner inventory.

The advantage is direct integration with the chat application. The constraint is the same one attached to any SDK workflow: your team must connect application state, campaign eligibility, event handling, and failure recovery correctly. The ledger-and-guard pattern keeps those responsibilities explicit in a 2026 implementation.

Troubleshooting

The campaign still serves after reaching its cap

The eligibility path is probably reading status from a stale cache or checking spend without reservations. Make the conditional reservation the final authority, and invalidate cached candidate lists after every relevant version change. Never treat cache invalidation as the only enforcement mechanism.

The campaign pauses before settled spend reaches the cap

Inspect reserved_minor. Open reservations count toward committed spend even though they have not settled. Expire or release abandoned reservations through a deterministic cleanup job, but do not remove valid reservations merely to make the displayed settled spend match the cap.

Spend increases twice after a retry

The charge consumer lacks an effective idempotency constraint. Persist event_id in the same transaction as the ledger update and reject duplicate identifiers at the database level. An in-memory duplicate check fails after process restarts and across multiple workers.

A manual pause disappears after a top-up

The resume query is too broad. Restrict its condition to status = 'paused_budget' and require the new cap to exceed committed spend. Manual and policy-driven pause reasons must remain untouched.

The scheduled job finds exhausted active campaigns

The real-time event, status write, or cache invalidation failed. Pause the campaign through the same conditional transition, publish the missing outbox event, and retain enough structured logs to identify which stage failed. The polling job is a repair loop, not the primary budget control.

Customize your workflow

Add alerts before exhaustion without weakening the hard cap. A 90% warning gives an account owner time to review the campaign, while the 100% guard remains the delivery authority. Treat those percentages as configurable policy, not embedded constants.

Multi-tenant platforms should keep separate advertiser, campaign, and publisher ledgers. Revenue-share calculations belong downstream from delivery enforcement so a reporting failure cannot change campaign eligibility. Use distinct events for reservation, settlement, release, exhaustion, restoration, and manual pause; that event history also supports a 2026 audit trail.

FAQ

One last thing

The pause worker is not the budget protection. The conditional reservation is. In 2026, build the hard stop into the delivery decision, then let alerts, webhooks, dashboards, and reconciliation describe or repair the state without controlling whether one more ad gets served.

Related guides

• Track ad impressions inside an AI chat app
• Build an AI chatbot ad revenue dashboard
• Sync AI chatbot ad revenue to Google Analytics