Sometime in the last month, a founder summed it up in one line on r/lovable: “App took off a bit, feeling overwhelmed!” A hundred and eight people upvoted it, and the title alone maps the whole genre: the app went viral, the founder is overwhelmed, and nothing they’d read on the way here covered this half.

That gap, between “people are actually using this” and “I don’t know what to do about it,” is the first 48 hours. Search for advice on a traffic spike and every result on the first page is about getting one: growth threads, launch checklists, how to get featured. Nothing on that page tells you what happens in the 48 hours after it works, which is exactly when three bills land on the same day. Across the 21 third-party apps AxonBuild audited in June and July 2026, 13 put no ceiling on how often their priciest endpoint could be called, 17 kept no record of any error anywhere, and the default Postgres tier most small apps run on stops accepting new direct connections at around 60. None of those three numbers shows up while you’re the only user. All three show up the day you aren’t.

Hour zero: which bill to stop first

The instinct when an app suddenly has users is to watch the signup counter. The more useful instinct is to go find the one endpoint that costs you money every time someone hits it: an AI call, an email send, a report generation, a webhook that fires a paid API in response. That endpoint is the one a crowd finds first, because a crowd is mostly the same handful of actions run thousands of times, and it’s the one most likely to have shipped with no limit on how often a single visitor can trigger it.

Rate limiting is the right first stop because it compounds fastest. A slow page costs you patience. An unmetered endpoint costs you dollars, per request, for as long as the spike lasts, and a spike that runs overnight while you’re asleep is the expensive version of this problem. A temporary cap, even a crude one (100 requests per IP per hour is a real limit; no limit is not), buys you the rest of this list without a bill you can’t explain to yourself later.

What breaks first when traffic arrives, and how you’d know

The honest answer for most vibe-coded apps is: you wouldn’t know, not from the app itself. Seventeen of those 21 apps gave an error nowhere to land, so a real request fails under load and nothing anywhere says so. The request just times out, or the customer sees a blank screen, and the only trace is a customer who doesn’t come back and never says why.

That silence is the actual danger of a traffic spike, more than the traffic itself. A crash is loud, and a slow response is at least visible. A caught exception that returns success anyway is invisible by design, and it’s the default shape an AI-built app tends to ship in, because the fastest way to make an error stop appearing in a demo is to catch it and do nothing. When your app fails silently and says 200 OK covers why that shape is so common; the point that matters on day one of a spike is narrower: if you don’t already have error tracking wired up, install it before you fix anything, because guessing at what’s broken under load wastes the hours you don’t have.

Will your app survive the spike? The load question

Somewhere in hour two or three, pages that were instant start feeling slow, and this is the question everyone actually means by “will my app survive a traffic spike.” The real mechanism is wiring, not raw capacity: a connection opened per request with nothing pooling them, a query that fires once per row instead of once per page, a list endpoint that returns however much the table holds. Each is invisible with one user and a hard ceiling under a hundred simultaneous ones, because that roughly-60-connection cap from the top of this post meets a serverless host that starts far more function instances than the database has seats, the moment requests stack up.

I’m not going to re-run that mechanism here, because why your AI app stalls at 100 concurrent users already walks it in full: the pooler, the missing index, and a drill you can run against seeded data instead of waiting for live traffic to run it for you. If your app is slowing down right now, that post is the next tab to open.

A traffic spike calls in three bills that were already accruing while nobody was watching.

The exposure question: a spike is when unauthenticated endpoints get found

The load question and the money question both assume the traffic is legitimate. Some of it won’t be. A spike is also the day a stranger, a competitor, or someone just poking at a trending link actually looks at what your app exposes, and a route nobody found in the first month of quiet use gets found on the day it has an audience.

One AI-powered CMS I audited made this connection concrete. Its passwordless login route had no rate limit and no cooldown at all: a single script could bomb any inbox, burning the sending quota and tanking the domain’s reputation in an afternoon. A few files over, an image-proxy route took any URL from the query string and fetched it server-side with no login and no allow-list, which is the kind of route that sits quietly for months and becomes a way to read the server’s own credentials the day someone with the right curiosity finds it. Both routes were missing the same thing: a check on who was allowed to call them at all. Under normal, low-traffic use, that gap is theoretical. Under a spike, it’s a matter of how many strangers pass through before one of them notices.

The rule underneath both: exposure and cost usually trace back to the same missing check, not two separate problems. Why AI coding tools ship security holes by default is the fuller version of why that check goes missing so consistently; the practical move today is to grep your own routes for the ones that touch money, email, or another user’s data and confirm each one actually checks who’s calling, not just whether they’re logged in.

The 48-hour hardening plan, in order

Everything above collapses into one sequence. Work it in order, because each step buys the time the next one needs, and none of it requires a rewrite:

  1. 01 Put a temporary rate limit on your single most expensive endpoint first, even a crude one, before anything else.
  2. 02 Turn on error tracking (a hosted SDK is minutes of setup) so the next failure shows up on a dashboard instead of disappearing.
  3. 03 Set a hard spend cap and a billing alert on your host, database, and any paid AI or email provider, so an unmetered burst can’t outrun your attention.
  4. 04 Grep every route that touches money, email, or another user’s data for a real authorization check, not just a login check.
  5. 05 Run the load drill from the 100-users post against your busiest endpoint before assuming the pooler and indexes are already in place.
  6. 06 If you have to hot-patch anything under the spike, remember it still deploys straight to the one database your customers are on; a rushed migration today is tomorrow’s outage.

That last item matters more than it looks like it should. One database, no staging is the default a viral day tempts you to forget about, right when a bad migration would cost you the most.

After the spike passes

Most spikes fade within a week, and the founders who come out ahead found their fragile endpoint before a stranger did. None of the three bills needed the spike to exist: the missing rate limit, the silent errors, and the unpooled connections were all in place before the first upvote, and a spike just moves up the due date. A rate limit, a place errors go to be seen, and a real check on who’s allowed to call your priciest route: none of that is glamorous, and all of it is cheaper before the next spike than during it.

The seven questions behind whether an AI-built app is actually ready to launch cover the rest of what a launch turns on; a viral day just forces the answer to three of them at once. Money leaking through a checkout is its own version of the same trap, and 6 ways your vibe-coded checkout leaks money is worth a read the moment the spike starts converting into paying customers instead of just visitors. Better luck wouldn’t have helped the founder on r/lovable. The rate limit, the error tracker, and the pooler, in place before the upvotes started, would have.

Common questions in the middle of a spike

Will my app survive a traffic spike?

If it was built with an AI tool and never load-tested, treat the answer as unproven rather than no. The ceiling is almost always wiring (pooled connections, indexed queries, capped list endpoints, a rate limit on the expensive endpoint), and each piece is checkable in an afternoon with the load drill linked above. In the 21 third-party apps AxonBuild audited in June and July 2026, the usual failure points showed up more often than not, so assume at least one applies to you until a drill says otherwise.

Should I upgrade my server or database plan during a spike?

Headroom is sometimes worth buying mid-spike, and it’s still the smaller half of the fix: a bigger instance moves the connection ceiling without adding the pooler, and it does nothing about an unmetered endpoint billing per call or errors disappearing unrecorded. Spend the first hour on the rate limit and the error tracker; upgrade after, if the dashboard you just installed says the load is real.

How do I stop a runaway bill during a traffic spike?

Cap it at both ends. Inside the app, a rate limit on the endpoint that costs money per call, even a crude per-IP one, stops the meter from spinning unattended. At your providers, a hard spend cap and a billing alert on the host, the database, and any paid AI or email service turn “unlimited” into a number you chose. Caps come first and diagnosis after, because every uncapped hour is a billed one.