Spend Cap vs Budget Alerts: Avoid Surprise Backend Bills

The surest way to avoid surprise backend bills is a spend cap: a hard limit that stops billable usage when it reaches the amount you allowed, instead of only e-mailing you. Budget alerts are useful, but they report spending after it happens, often hours later, and most do not stop anything. Combine a cap (or prepaid credit) with per-project budgets, rate limits and a few code habits, and a runaway loop or a traffic spike stays an annoyance instead of an invoice.

This guide explains the difference between caps and alerts, what common platforms actually do, and a checklist you can apply to any backend.

#A spend cap is not a budget alert

Three mechanisms get called "budgets", and they behave very differently:

Alerts depend on you reacting, at 3 a.m., before more damage is done. Caps and prepaid credit do not.

#What common platforms do (as of November 2026)

Google Cloud and Firebase. Firebase's guide to avoiding surprise bills states that budget alerts do not pause services. It also describes spend-cap budgets that pause a service at 100% of its budget for the rest of the month, but only for some products: Firebase AI Logic, App Hosting, Cloud Functions for Firebase and Firebase Extensions. For the rest, Google suggests you can use budget notifications to disable billing on the project programmatically, which you have to build.

AWS. AWS Budgets track costs and send alerts, and budget actions can apply restrictions such as an IAM policy that blocks new resources. AWS's budgets docs say budget data is updated up to three times a day and note that you can incur costs beyond your threshold before you are notified.

Supabase. Supabase's cost control docs describe a spend cap on the Pro plan. With it on, usage of covered items (such as disk size, egress, Edge Function invocations, MAU, Realtime and storage) is blocked once the quota is exceeded until the next cycle. Some items are not covered by the cap, including compute, branching compute, read replica compute, custom domains, IPv4 and point-in-time recovery, because they are opted into explicitly. The docs also say there are no per-item budgets or cost-threshold notifications.

StitchDB. Paid plans start with the spend cap on: usage stops at the plan's included amounts, so you never pay more than the plan price. If you turn the cap off, extra usage is paid from prepaid credit, with a monthly spending cap on top (default $20). Per-project budgets add alerts and optional hard stops. Details below.

Each model has a case. AWS and Google give you the most flexibility and the widest service catalog; their billing tools assume you will build automation around them. Supabase's cap is simple and covers the common usage items. StitchDB's model is built so that no path leads to debt, at the cost of stopping usage when limits are hit, which you have to plan for.

#Why bills explode

Most surprise bills come from a short list:

• A loop that calls the API. A React useEffect without dependencies, a retry without backoff, a cron job that triggers itself.
• Egress from public files. A large video or image linked from a popular page or scraped by bots.
• Image transformations with unbounded sizes or parameters, each a new billable transform.
• Auth e-mail and SMS abuse. Bots requesting magic links or SMS codes to many numbers.
• Functions that recurse or call themselves through a webhook.
• Forgotten resources. Preview environments, replicas or dedicated servers left running.
• Leaked keys. A service key in a public repo used to mine or exfiltrate.

#How StitchDB's spend controls work

#How the spend cap works

Paid plans start with the spend cap on. Usage stops at the plan's included amounts, and the bill is the plan price. Turn it off in Billing to keep going above the included amounts; the dialog shows the rates and what your current usage would cost this month before you confirm. Only the account owner can change it, and it applies to all projects of the organization. Enterprise starts with the cap off. Free always has hard limits. See Spend cap.

What "stops" means depends on the resource. For example, when a database goes over its size limit with the cap on, it becomes read-only: reads keep working, writes fail with a clear error, and nothing is deleted. See Database limits.

#Prepaid credit and a monthly spending cap

With the cap off, usage above the included amounts is charged from prepaid credit every hour. Two limits always apply: the credit balance and the monthly spending cap (default $20). When either is reached, the plan's included limits apply again until you add credit or the month ends. There is never debt. Automatic top-up is optional. See Billing.

Usage prices on Pro (as of November 2026) include $0.12 per GB of database above the included size, $0.02 per GB of file storage and egress, $0.002 per monthly active user, and $1 per million Edge Function invocations or realtime messages.

#Per-project budgets

Account-wide caps do not tell you which project is misbehaving. Budgets are per project, per resource, per month:

Alerts go out at the percentages you choose (50%, 80% and 100% by default, up to six thresholds, also above 100%) by e-mail, webhook or Telegram. Usage is checked every 5 minutes. A webhook alert looks like this:

{
  "type": "budget.alert",
  "record": {
    "resource": "egress_gb",
    "threshold": 100,
    "used": 10.2,
    "budget": 10,
    "percent": 102,
    "stopped": true,
    "period": "2026-10"
  }
}

A budget does not change what you are billed; it stops usage. To never pay above your plan across the account, keep the spend cap on.

#Costs shown before you commit

Every action that changes the bill (extra project, plan change, turning the cap off, read replicas, branches, dedicated servers) shows its monthly cost, the prorated amount for this month and whether your credit covers it, before you confirm.

#A checklist for any backend

#Limits and caps

• Turn on a hard cap if your provider has one. Know which items it covers.
• If there is no cap, use prepaid credit or a low-limit card where possible.
• Set budget alerts at 50%, 80% and 100%, to a channel someone reads.
• Set per-project budgets, so one project cannot drain the others.

#Code habits

• Add backoff and a maximum to every retry loop.
• Check useEffect and similar hooks for missing dependency arrays.
• Debounce search-as-you-type queries.
• Paginate; never select whole tables from a client.
• Make functions idempotent and guard against self-triggering webhooks.

#Abuse protection

• Rate-limit sign-in, sign-up, magic link and SMS endpoints. StitchDB has per-plan auth rate limits you can lower; see Auth limits.
• Add bot protection to public forms.
• Protect expensive endpoints with authentication.
• Cap upload sizes per bucket.

#Storage and egress

• Do not hotlink large public files from popular pages without a CDN.
• Use image resizing with fixed presets rather than arbitrary sizes.
• Set cache headers on public assets.

#Housekeeping

• Delete preview branches when pull requests close (automate it).
• Review running replicas, dedicated servers and extra projects monthly.
• Rotate any key that has been exposed, immediately.

#Plan for the stop

A cap means usage stops. Decide in advance what your app does when it does:

• Show a friendly message on 402 or 429 instead of a crash.
• Make writes fail clearly when the database is read-only.
• Alert the team when a stop happens, so it is resolved in hours, not days.

#FAQ

#Is a spend cap bad for growth?

It can stop a real traffic spike. Many teams keep the cap on in early stages and turn it off with a monthly spending cap once usage is predictable.

#Do budget alerts arrive in real time?

Usually not. AWS documents updates up to three times a day; StitchDB checks budgets every 5 minutes. Treat alerts as a signal, not a brake.

#What happens to my data when a cap is reached?

On StitchDB, nothing is deleted. Over the database size limit the database becomes read-only until you free space or raise the limit.

#Can I cap one project but not another?

On StitchDB, the spend cap is account-wide, and budgets with a stop at 100% are per project.

See plan prices and usage rates on the pricing page, or read BaaS Pricing Compared.