A traffic spike does not fail your server politely. On budget plans it usually hits the invoice before it hits the CPU, because bandwidth, connections, and API calls are metered and billed monthly while the spike lasts a single day. A site that handles 10x traffic without slowing down can still produce a bill that is 3–4x normal.
The fix is not to buy a bigger plan. It is to model the spike’s cost before it happens, and to decide in advance which resources absorb it and which ones bill for it.
Establish the baseline numbers
You cannot size a spike without knowing per-visitor consumption. Measure it over a normal week rather than estimating from page weight:
# bytes served and requests per day from nginx logs
awk '{sum+=$10} END {print sum/1024/1024" MB total"}' /var/log/nginx/access.log
wc -l < /var/log/nginx/access.log
# per-visitor averages (unique IPs as a rough visitor count)
awk '{print $1}' /var/log/nginx/access.log | sort -u | wc -lTypical small business site figures: 2–5 MB transferred per visitor, 12–40 requests, with images and uncached assets dominating. A site doing 5,000 visitors per month at 3 MB each consumes roughly 15 GB — well inside almost any included transfer allowance, which is why spikes catch people off guard.
Model the spike
Take your normal day, multiply by the spike factor, and price the excess at your provider’s overage rate — not the plan price.
| Scenario | Visitors | Transfer @3 MB | Beyond 1 TB included | Overage @$0.01/GB |
|---|---|---|---|---|
| Normal day | 170 | 0.5 GB | 0 | $0.00 |
| Viral day (10x month in one day) | 50,000 | 150 GB | 0 | $0.00 |
| Hard spike on media-heavy site | 50,000 | 1,250 GB | 250 GB | $2.50 |
| Same, at $0.05/GB overage | 50,000 | 1,250 GB | 250 GB | $12.50 |
| Two weeks sustained at 10x | 700,000 | 2,100 GB | 1,100 GB | $11–$55 |
Two conclusions fall out immediately. First, overage rates differ by 5x between providers, and that matters more than the plan price during a spike. Second, media weight per visitor drives the entire model — a 3 MB visitor becomes a 25 GB difference per 10,000 visitors.
The three resources a spike actually exhausts
- Transfer. Billed, recoverable, and the only one with a direct invoice impact. Reduce it with caching and a CDN.
- Concurrent connections and workers. Not billed, but the first thing to fail. PHP-FPM or Node worker pools hit their ceiling and requests queue.
- Database connections and IOPS. Not billed on most budget plans, but the slowest to recover — a saturated disk stays slow for minutes after the spike ends.
Budget plans fail in that order. Bandwidth overage is annoying; worker exhaustion is the outage.
Cap the bill before the spike arrives
Most budget providers let you set a spend cap or a bandwidth limit. Set it now, not during the incident:
# nginx: cap concurrent connections per IP to blunt bot-driven spikes
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;
limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s;
limit_req zone=req burst=20 nodelay;
# PHP-FPM: size the pool to survive, not to serve
; pm.max_children = (available_RAM_MB - 300) / avg_worker_MB
pm = dynamic
pm.max_children = 12
pm.max_requests = 500Rate limiting has a second benefit: it converts a bandwidth bill into a 429 response, which costs nothing. For a spike dominated by crawlers or a single abusive source, that alone can cut transferred bytes by 70%+ while leaving real users unaffected.
Cache and CDN: the highest-return spike insurance
Everything served from a cache is bandwidth you do not pay for and workers you do not consume. For spike budgeting specifically:
- Serve all static assets through a CDN. This typically removes 60–85% of a small site’s transferred bytes.
- Enable full-page caching for anonymous traffic so repeat visitors never reach PHP.
- Set short TTLs on HTML during known events, long TTLs on assets year-round.
- Compress text and images at the edge, not on the origin — the origin then uploads once, not per visitor.
With a CDN in front, a 10x visitor day often translates to less than 2x origin transfer, because the CDN absorbs repeats. That is the difference between a $2 spike and a $60 one.
The pre-spike checklist
- Compute your bytes-per-visitor from logs, not estimates.
- Multiply by your realistic worst-case spike and price the excess at the overage rate.
- Confirm the provider’s overage rate and whether overage can be capped or blocked.
- Move static assets to a CDN and enable page caching.
- Add connection and request rate limits sized to protect workers, not to serve everyone.
- Decide the upgrade trigger in advance: a specific concurrent-connection number, not a feeling.
Run those six steps and a spike becomes a capacity event rather than a billing event. To see which plans include enough transfer to absorb a 10x day without overage — and which bill heavily past the cap — compare budget VPS plans side by side on included transfer and overage rate, not headline price.
One final note: verify your overage rate by checking a real invoice after any spike. Providers occasionally adjust metered rates mid-term, and a $0.01/GB assumption from signup is not guaranteed for the life of the plan. That is also worth building into the plan-selection step itself — our VPS comparison table records included transfer and metered rates per plan so the spike cost is visible before you buy, not after.
