You have found out. You are not at a laptop. Here is the order.
The instinct is to work out what is happening before doing anything drastic. Resist it. Every minute of investigation is billable, and pausing is reversible. Stop it, then investigate from a position where the meter is not running.
1. Stop the bleeding (60 seconds)#
Vercel: pause the project. vercel.com works in mobile Safari — project →
Settings → General → pause. Or from an app with a kill switch, if you have one.
Netlify: there is no pause. Set a site password, which makes the site inaccessible and stops the traffic. See the Netlify kill switch.
If you know it is one identifiable source — one IP range, one crawler — block it at the firewall instead and leave the site up. Better outcome, slightly more fiddly on a phone. If you are not sure, pause; you can refine it later.
2. Confirm it stopped (2 minutes)#
Check the usage graph and watch the line flatten. Do not skip this. Pausing the wrong project, or pausing a project whose cost is coming from a function still running elsewhere, is a real failure mode and you want to know now rather than in the morning.
3. Work out what it was (10 minutes, still on the phone)#
Usage breakdown, per project, and look for the line item that is disproportionate rather than largest:
- Image optimization high relative to page views → a crawler. Why.
- Bandwidth far above what analytics say humans used → bots or an attack.
- Function duration or invocations spiking with no traffic change → a retry loop. The fastest-moving one.
- Build minutes climbing → a build loop or a monorepo rebuilding everything.
- Edge requests far above page views → middleware on routes it should not be on, or client-side polling.
4. Decide whether to restore now or in the morning#
Restore now if you have identified the cause and can fix or block it from where you are — a firewall rule, disabling one route, reverting a deploy.
Leave it paused if you have not. A site being down until morning is a known, bounded cost. A site that is up and billing at an unknown rate is not.
That is an uncomfortable trade at 2am with users depending on you. It is still usually the right one, and it is much easier to make if you decided the policy in advance rather than while half asleep.
5. In the morning#
- Fix the cause properly.
- Add the preventative layer you did not have — WAF, caching, bounded image variants, ignore rules.
- Contact support. Refunds for clear-cut attack traffic happen more often than people expect. Ask politely, include the usage graph and the timeline.
- Set a threshold lower than the one that let this happen.
Doing better than finding out at 2am#
Everything above starts with "you have found out", which is the part that usually goes wrong. In every documented case, discovery was after the fact — the invoice, the usage email, a platform notification.
The options for finding out sooner: Vercel's own spend alerts if you are on Pro (and with the pause switch actually on), a cron polling the billing API, or something that pushes your phone.
MONII is the last of those, and the reason it exists is step 1: the alert and the kill switch are the same screen, so the gap between knowing and stopping is a swipe rather than a scramble for a laptop.
Questions people actually ask
What should I do first if my hosting usage is spiking?
Stop the bleeding before diagnosing. Pause the project or block the traffic, then work out what happened. Every minute spent investigating first is billable.
Can I pause a Vercel project from a phone?
Yes — vercel.com works in mobile Safari, or via the API from a shortcut, or from an app with a kill switch. All three work; the difference is how many seconds it takes.
One swipe, from the lock screen
MONII puts the alert and the kill switch in the same place, so finding out and stopping it are one gesture rather than a scramble.
Get MONII for iOS ›