Monitoring During Traffic Spikes — Your Site Slows Down Before It Falls Down

If your site is busier this year than it has ever been, you're in good company. The last four months have pushed an extraordinary amount of daily life online — remote work, grocery delivery, curbside pickup, video everything — and by some estimates overall internet traffic jumped 25–40% in a matter of weeks this spring. For a lot of small e-commerce shops and SaaS apps, "a good day" in 2020 looks like what "getting linked from the front page of Reddit" looked like in 2019. The difference is that this load isn't a one-hour spike. It's the new baseline, with spikes on top.

Here's the thing most teams learn the hard way: sites under load almost never go from healthy to dead in one step. They get slow first — sometimes for hours — and slowness is a signal you can act on. This post is about reading that signal, knowing which capacity limits you'll hit first, and adjusting your monitoring so a surge is an event you manage instead of an outage you apologize for.

Response time is your early-warning system

A hard "down" alert tells you the fire has already started. Response-time trends tell you the room is filling with smoke.

When a server approaches saturation, latency degrades in a recognizable pattern — and it's not linear. A page that renders in 300 ms at 40% capacity might take 500 ms at 70%, 2 seconds at 90%, and then the queue backs up and requests start timing out entirely. That curve is brutal near the top: the difference between "slow" and "down" can be a 10% increase in traffic.

Which means the useful monitoring question isn't only "is the site up?" — it's "is the trend bending?" Watch for:

• Baseline drift. Your homepage averaged 400 ms for months and it's averaging 900 ms this week. Nothing is "down," but you've quietly spent your headroom.
• Widening variance. Average looks fine but the slowest checks are getting much slower — a classic sign of connection queues forming and some requests drawing the short straw.
• Time-of-day correlation. If latency climbs every evening as traffic peaks and recovers overnight, you have a capacity problem on a timer, and you can predict roughly when it becomes an outage.

If your monitoring records response time on every check — not just up/down — you already have this data. Set an alert threshold on sustained latency (say, "over 2 seconds for 10 minutes") and you'll routinely get hours of warning before a hard failure.

Know which wall you'll hit first

"Capacity" isn't one number. Under load, systems fail at their narrowest bottleneck, and it pays to know yours in advance:

• Database connections. Usually the first wall for dynamic sites. Each PHP worker or app process holds a connection; traffic doubles, the pool exhausts, and new requests error or queue. Watch your connection count against its ceiling.
• Worker/process limits. Apache's MaxRequestWorkers, PHP-FPM's pm.max_children, your app server's thread pool. When these saturate, requests queue at the front door — latency climbs long before errors appear.
• CPU and memory. Obvious, but check steady-state levels, not just spikes. A box idling at 75% CPU has no room for a 2× day.
• Upstream dependencies. Payment providers, email APIs, inventory services — your surge is often their surge too. A checkout that waits 20 seconds on a slow third party ties up your workers just as effectively as your own bug.
• Bandwidth and connection limits at your host or load balancer. Cheap VPS plans often throttle before the OS complains.

A quick, honest exercise: look at your busiest hour last month, double it, and ask which of the above breaks first. That's the thing to fix or monitor most closely.

Caching and a CDN — the cheapest headroom you can buy

Before you reach for bigger servers, reach for fewer requests:

• Full-page caching for anonymous traffic. Most spike traffic hits a handful of public pages — product pages, articles, the homepage. Serving those from cache (Varnish, nginx's proxy_cache, or your framework's page cache) can cut origin load by an order of magnitude.
• A CDN for static assets — images, CSS, JS. This offloads the bulk of bandwidth and connection count to someone else's network, and free tiers exist. In 2020 there is very little excuse for serving images straight off your origin.
• Sane cache headers, so browsers stop re-requesting what they already have:

location ~* \.(css|js|png|jpg|jpeg|gif|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

• Micro-caching dynamic pages for even 10–30 seconds. During a spike, a page rebuilt once every 10 seconds instead of 300 times a second is the difference between calm and collapse — and almost no visitor will notice.

None of this replaces capacity planning. It buys you multiples of headroom for hours of work, which is exactly what you want when traffic charts only go up.

Monitoring during a surge is different from monitoring at rest

The monitoring configuration that served you fine at normal load needs adjusting when things get busy:

• Tighten your check interval. During elevated load, minutes matter — a check every few minutes leaves a long blind spot exactly when problems develop fastest.
• Watch the money paths, not just the homepage. The homepage is often cached and healthy while checkout — dynamic, database-heavy, dependent on a payment API — is drowning. Monitor the pages that fail first and cost most.
• Check from outside your network. Load problems often manifest at the edge — connection limits, SSL handshake queues — that internal health checks on localhost sail past.
• Alert on slow, not just down. Set a response-time threshold and treat sustained breaches as an incident. "Slow" is the incident; "down" is just its final act.
• Don't relax thresholds to stop the noise. If latency alerts fire daily, that's the system telling you something. Muting the smoke detector doesn't put out the fire.

And after the spike: keep the data. Response-time history from your busiest week is the best capacity-planning document you'll ever get for free.

Watch the trend, not just the pulse

The surge in online traffic this year isn't a blip to wait out — for most businesses it's the new floor. The sites handling it gracefully aren't the ones with the biggest servers; they're the ones who saw the latency curve bending and acted a day early.

CompleteStatus records response time on every single check and charts the trend, so baseline drift is visible at a glance — and you can alert on sustained slowness, not just hard downtime, alongside the usual up/down checks from one dashboard. Create a free account, point a monitor at your homepage and one at your checkout, and you'll know about your next capacity problem while it's still just a slope on a graph.