Security incidents happen when someone attacks you. This one happens with nobody attacking at all. Your own bug is sufficient.
And you usually find out when the invoice arrives.
1. Why it spikes — usage billing has no ceiling
Old shared hosting was "1,000 yen a month, use as much as you like." Overuse just made the site slow; the bill didn't change.
Modern cloud services are the opposite. You are billed for what you use, and there is no ceiling unless you set one. Under load nothing slows down — it scales, and you are billed accordingly.
That is a benefit by design: a sudden traffic spike doesn't take your service down. The catch, and the subject of this article, is that "more traffic" isn't always legitimate traffic.
2. The five patterns that spike
Pattern 1: AI API calls
The most dangerous.
OpenAI and Anthropic APIs have a per-request unit cost orders of magnitude above other cloud services, and it grows with the length of the input.
Dangerous implementations AI tends to write:
- Resending the whole conversation history every time — each call gets more expensive as the conversation goes on
- No limit on the length of text a user can submit — one long paste is expensive on its own
- No cap on retries — a persistent error repeats the same call
- Usable without logging in — anyone can call it, without limit
The last one bites hardest. Opening an AI feature without login "so people can try it" creates a window through which anyone can use AI on your money.
Pattern 2: image and video conversion
Image optimisation, thumbnail generation, video encoding. These are heavy, and many services bill per conversion or by data transfer.
The problem is the same image being converted repeatedly. Without caching — reusing what was already produced — a conversion runs every time the page renders.
Pattern 3: infinite loops
The quietest and fastest way to spike.
[what happens]
- process A calls process B, and process B calls process A
- a process triggered by a data update updates data itself
- a process that retries on failure keeps failing and retrying
The third is especially common. Ask an AI to "retry if an error occurs" and, unless you specify a limit, it may write code that retries forever.
Loops are invisible to you. They spin quietly on the server.
Pattern 4: bot crawling
A published site attracts search-engine and AI crawlers. That is normal.
But if you have many pages that contain heavy processing, crawlers walk all of them.
- Search-result pages generated endlessly (
?page=1through?page=99999) - A calendar feature generating infinite future dates
- Filter combinations exploding the URL space
These produce "infinitely many URLs with effectively the same content," and crawlers dutifully visit them all.
Pattern 5: the moment you exceed a free tier
Finally, an assumption problem.
"I'm on the free plan, so no bill can arrive" — this differs per service.
- Exceed the free tier and the service stops → no bill (but the service is down)
- Exceed the free tier and billing switches to usage-based automatically → a bill arrives
Check which behaviour applies before you launch. Some services move to the second the moment you register a card.
3. Countermeasure 1: set a hard spending cap (highest priority)
This comes first.
Why "billing alerts" aren't enough
Many people set a billing alert and feel safe. But an alert only tells you that you overspent — it doesn't stop anything.
Suppose an infinite loop starts at 2am. The alert arrives at 2:30. You notice at 7am. That four and a half hours is billed in full.
What you want is not a notification but a hard spending cap.
Where to set it, per service
Vercel — the Spend Management feature lets you configure what happens when a monetary threshold is reached. Beyond notification, you can choose to pause deployments. Check the official documentation for which plans and options apply.
AI APIs (OpenAI / Anthropic and others) — the dashboard lets you set per-key and per-organisation usage limits. Set these without exception. Specify an amount and it stops there. Separating development and production keys and capping each is safer still.
Supabase — check the per-plan limits and how overage is billed. If a spend cap setting exists, enable it.
Cloud generally (AWS / GCP) — budget alerts are configurable, but automatic shutdown is not included by default. Automating a stop requires additional machinery.
Two things to confirm
For every service, confirm:
- What happens when the cap is reached — does it stop, or keep billing
- If it stops, how do you recover — the procedure at 2am
A "stop" setting means, by definition, "the service goes down." For a solo project, an unbounded bill is almost always worse than downtime — but that is a choice you should make yourself.
4. Countermeasure 2: add rate limiting
Where a spending cap sets the ceiling on damage, rate limiting stops the volume happening at all.
Rate limiting restricts how many requests one person can make in a period — "10 per minute per person," for instance.
With only a cap, the service stops. With only rate limiting, there is no ceiling. Both together give you a service that neither goes down nor runs up a bill.
Where to apply it
Not everywhere. Only where the cost is high is enough.
- Anything calling an AI API ← highest priority
- Image and video conversion
- Anything calling a paid external API
- Sending email
- Heavy aggregation or search
Requiring login alone helps
Simply putting AI features behind a login materially reduces indiscriminate abuse. The wish to "open it up free so people can try it" is understandable — but if you open it, pair it with a usage limit.
5. Countermeasure 3: remove the causes in advance
Caps and rate limiting exist so that an incident doesn't hurt. Some prevention is cheap to add too.
Cap retries. Decide "three times, with a delay." Never retry forever.
Limit what you send to an AI. Set a character limit, and send only the last N messages of history.
Cache conversion results. Don't reconvert the same image every time.
Narrow what crawlers see. Use robots.txt to exclude search-result pages and filter-combination pages. Not generating infinitely many URLs with effectively identical content is a design question too.
Set timeouts. Don't wait indefinitely on an external service — you are billed while waiting.
6. The instruction to paste into your AI tool
List every usage-billed service this app depends on and produce a table with,
for each one:
(1) What is billed (request count, data transfer, execution time, tokens)
(2) A concrete scenario in which cost spikes unexpectedly
(3) The caps and alerts available in its dashboard
Then read the code and check for these dangerous implementations.
- Retries with no upper limit
- No limit on the length of input sent to an AI API
- Sending the entire conversation history every time
- Conversions that run every time because nothing is cached
- Expensive operations callable without logging in
- External calls with no timeout
- Places where processes may call each other (the seed of an infinite loop)
Finally, implement rate limiting on the highest-cost endpoints. Explain in plain
language which endpoints you limited, to what values, and why. I cannot read code.
7. A checklist for right after launch
- Listed every service in use, free tiers included
- Confirmed, per service, what happens when the free tier is exceeded (stop or bill)
- Set a hard spending cap wherever one is available
- Set a per-key spending limit on AI APIs
- Set billing alerts (alongside caps, not instead of them)
- Added rate limiting to high-cost operations
- Put AI features behind a login, or added a usage limit
- Capped retries
- Set timeouts on external calls
- Excluded infinitely-generated URLs in
robots.txt - Look at the billing page once a day for the first week after launch ← the most effective item
That last one matters more than it looks. A spike almost always begins as a small anomaly. Looking daily means noticing on day one.
Summary
- Usage billing has no ceiling. It spikes from your own bug, with nobody attacking
- Five patterns: AI APIs, image and video conversion, infinite loops, bot crawling, the automatic switch after a free tier
- AI APIs are the most dangerous — high unit cost, more expensive with longer input. Per-key caps are mandatory
- Billing alerts are after-the-fact notifications. Use a hard spending cap where available
- Rate limiting is needed separately. A cap is the ceiling on damage; rate limiting stops it happening
- Look at the billing page daily for the first week. Spikes start small
This is a "right after launch" item rather than a "before launch" one, but deferring it comes back as a painful expense. Once the four pre-launch items are closed, this is next.