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\u20134x normal.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
You cannot size a spike without knowing per-visitor consumption. Measure it over a normal week rather than estimating from page weight:<\/p>\n\n\n\n
# bytes served and requests per day from nginx logs\nawk '{sum+=$10} END {print sum\/1024\/1024\" MB total\"}' \/var\/log\/nginx\/access.log\nwc -l < \/var\/log\/nginx\/access.log\n\n# per-visitor averages (unique IPs as a rough visitor count)\nawk '{print $1}' \/var\/log\/nginx\/access.log | sort -u | wc -l<\/code><\/pre>\n\n\n\nTypical small business site figures: 2\u20135 MB transferred per visitor, 12\u201340 requests, with images and uncached assets dominating. A site doing 5,000 visitors per month at 3 MB each consumes roughly 15 GB \u2014 well inside almost any included transfer allowance, which is why spikes catch people off guard.<\/p>\n\n\n\n
Model the spike<\/h2>\n\n\n\n
Take your normal day, multiply by the spike factor, and price the excess at your provider’s overage rate \u2014 not the plan price.<\/p>\n\n\n\nScenario<\/th> Visitors<\/th> Transfer @3 MB<\/th> Beyond 1 TB included<\/th> Overage @$0.01\/GB<\/th><\/tr><\/thead> Normal day<\/td> 170<\/td> 0.5 GB<\/td> 0<\/td> $0.00<\/td><\/tr> Viral day (10x month in one day)<\/td> 50,000<\/td> 150 GB<\/td> 0<\/td> $0.00<\/td><\/tr> Hard spike on media-heavy site<\/td> 50,000<\/td> 1,250 GB<\/td> 250 GB<\/td> $2.50<\/td><\/tr> Same, at $0.05\/GB overage<\/td> 50,000<\/td> 1,250 GB<\/td> 250 GB<\/td> $12.50<\/td><\/tr> Two weeks sustained at 10x<\/td> 700,000<\/td> 2,100 GB<\/td> 1,100 GB<\/td> $11\u2013$55<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTwo 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 \u2014 a 3 MB visitor becomes a 25 GB difference per 10,000 visitors.<\/p>\n\n\n\n
The three resources a spike actually exhausts<\/h2>\n\n\n\n- Transfer.<\/strong> Billed, recoverable, and the only one with a direct invoice impact. Reduce it with caching and a CDN.<\/li>
- Concurrent connections and workers.<\/strong> Not billed, but the first thing to fail. PHP-FPM or Node worker pools hit their ceiling and requests queue.<\/li>
- Database connections and IOPS.<\/strong> Not billed on most budget plans, but the slowest to recover \u2014 a saturated disk stays slow for minutes after the spike ends.<\/li><\/ul>\n\n\n\n
Budget plans fail in that order. Bandwidth overage is annoying; worker exhaustion is the outage.<\/p>\n\n\n\n
Cap the bill before the spike arrives<\/h2>\n\n\n\n
Most budget providers let you set a spend cap or a bandwidth limit. Set it now, not during the incident:<\/p>\n\n\n\n
# nginx: cap concurrent connections per IP to blunt bot-driven spikes\nlimit_conn_zone $binary_remote_addr zone=perip:10m;\nlimit_conn perip 20;\nlimit_req_zone $binary_remote_addr zone=req:10m rate=10r\/s;\nlimit_req zone=req burst=20 nodelay;\n\n# PHP-FPM: size the pool to survive, not to serve\n; pm.max_children = (available_RAM_MB - 300) \/ avg_worker_MB\npm = dynamic\npm.max_children = 12\npm.max_requests = 500<\/code><\/pre>\n\n\n\nRate 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.<\/p>\n\n\n\n
Cache and CDN: the highest-return spike insurance<\/h2>\n\n\n\n
Everything served from a cache is bandwidth you do not pay for and workers you do not consume. For spike budgeting specifically:<\/p>\n\n\n\n
- Serve all static assets through a CDN. This typically removes 60\u201385% of a small site’s transferred bytes.<\/li>
- Enable full-page caching for anonymous traffic so repeat visitors never reach PHP.<\/li>
- Set short TTLs on HTML during known events, long TTLs on assets year-round.<\/li>
- Compress text and images at the edge, not on the origin \u2014 the origin then uploads once, not per visitor.<\/li><\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
The pre-spike checklist<\/h2>\n\n\n\n- Compute your bytes-per-visitor from logs, not estimates.<\/li>
- Multiply by your realistic worst-case spike and price the excess at the overage rate.<\/li>
- Confirm the provider’s overage rate and whether overage can be capped or blocked.<\/li>
- Move static assets to a CDN and enable page caching.<\/li>
- Add connection and request rate limits sized to protect workers, not to serve everyone.<\/li>
- Decide the upgrade trigger in advance: a specific concurrent-connection number, not a feeling.<\/li><\/ol>\n\n\n\n
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 \u2014 and which bill heavily past the cap \u2014 compare budget VPS plans side by side<\/a> on included transfer and overage rate, not headline price.<\/p>\n\n\n\n