Running & Maintaining a Site

Traffic Spike

Definition

A traffic spike is a short period when requests to a site run far above its normal level: ten times, a hundred times, occasionally more. The causes are mundane and mostly external — a post that does well on a large forum, a newsletter with a big list, a press mention, a launch, or a scraper that decides to fetch everything at once. Spikes are shaped differently from steady growth: they arrive in minutes, concentrate on one or two URLs, and decay over a day or two. What matters operationally is not the monthly total but the peak rate, measured in requests per second and megabytes per second. A static site sitting behind a CDN absorbs one far more easily than an application server does, because there is nothing to compute and the work is spread across the edge.

Why It Matters

A dynamic site usually fails at its slowest part: the database, the pool of application processes, the memory on one machine. Past a few hundred concurrent requests the queue grows, response times climb, and the site stops answering — precisely when the largest audience it has ever had is looking at it. Static files have no equivalent ceiling, so the failure mode shifts from downtime to money and quota. A 2 MB page served to 200,000 people in one afternoon is 400 GB of transfer, which on a metered plan is a real egress fee and on a capped plan can be a hard stop halfway through.

How It Works

When a request reaches a CDN location, the edge either has the file cached and answers immediately, or fetches it once from the origin and then serves everyone else behind that copy. During a spike the first few requests per location are misses and all the rest are hits, so origin load stays roughly flat however steep the curve gets. This only holds if the files are genuinely cacheable: a Cache-Control header with a tiny max-age, or a URL carrying a unique query string per visitor, turns every request back into an origin fetch and the advantage vanishes. Watch the cache hit ratio during a spike rather than the raw request count — a ratio falling as traffic climbs is the warning sign. What still breaks is everything that is not a static file: third-party fonts and scripts the page waits on, an embedded form posting to somebody else's endpoint, an analytics service with its own rate limits, and any per-plan bandwidth cap that stops serving once reached.

Real-World Example

A researcher publishes a 12-page report as a single HTML page with three images at soil-survey.99helpers.site. It sits at 40 views a day for a month, then gets linked from a widely read newsletter and takes 90,000 views in eighteen hours. The pages never wobble, because the edge serves the same cached HTML to everyone. What does move is transfer: at roughly 1.4 MB per view, that afternoon shifted about 125 GB, which is the number worth checking against the plan before the link goes anywhere large.

Common Mistakes

  • Assuming a static site is unaffected — the pages stay up, but bandwidth allowances and metered transfer run down at exactly the speed of the traffic
  • Leaving the heaviest asset unoptimised until the day it matters — a 4 MB hero image multiplies by every single visitor, and a spike is the worst moment to notice
  • Publishing a content change at the same moment as a big launch link, so the caches are cold and the origin takes the whole first wave

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →