Slow Is the New Down — Why Performance Is Availability

Your uptime monitor says 100%. Your users say the site is down. You're both right — and that's the problem. A page that takes twelve seconds to respond will pass any conventional uptime check with flying colors, because the check's question is "did the server answer before my 30-second timeout?" Your visitor's question is different: "did this thing load before I gave up?" — and their timeout is measured in single-digit seconds, enforced by a thumb hovering over the back button.

The binary up/down model of availability made sense when the alternative to a working site was a connection error. In practice, most availability loss today happens in the gray zone between fast and dead — and if your monitoring only alerts on dead, you're measuring the smallest slice of the problem.

Users time out long before your server does

The research on this has been remarkably consistent for years, and while exact figures vary by study and industry, the shape never changes:

• Abandonment starts early. Widely cited findings — including Google's own mobile research — put the odds of a visitor bouncing up sharply once load time passes about three seconds; by some estimates a majority of mobile visits are abandoned at that threshold.
• Seconds cost conversions, at double-digit rates. Retail studies have long reported that an extra second or two of load time can cut conversions by ten percent or more per second. The famous old figures from Amazon (every 100ms costs ~1% of sales) may be dated, but every retest lands in the same neighborhood: the curve is steep exactly where most degraded sites live.
• Search engines have made it official. Since Google's "Speed Update" rolled out in July 2018, page speed is a ranking factor for mobile searches. A slow site now loses visitors it never even had — they were filtered out on the results page.

Put together: a site responding in 8–15 seconds has, for business purposes, most of the availability loss of a hard outage — while generating none of the alerts.

Degradation is how outages introduce themselves

Here's the operational reason to watch response times, even if you don't care about conversion curves: most outages aren't born as outages. They start as slowness, minutes or hours earlier, because the classic failure mechanisms are gradual:

• Connection-pool exhaustion. The database pool has 100 slots. A slow query makes each connection linger a bit longer; utilization creeps up; requests start queueing for a free slot. Response times climb steadily — 300ms, 900ms, 3 seconds — until the pool saturates and everything hard-fails at once. The up/down monitor fires at the last step. The response-time trend was screaming for half an hour.
• The swap death-spiral. A memory leak nudges the server into swap. Everything slows; requests pile up; piled-up requests hold more memory; the machine swaps harder. From the outside this reads as response times doubling every few minutes — a curve so distinctive you can diagnose it from the monitoring graph — ending in a load average in the hundreds and a server that might as well be off.
• Slow-burn resource leaks — file handles, worker threads, disk filling with logs. Each produces the same signature: a healthy baseline, then a drift, then a cliff.

The pattern is the point. The cliff is the outage; the drift is the warning. Response-time monitoring is how you get paged at the drift — while the site is still up and the fix is a calm restart instead of a 2 AM incident.

Alert on latency, not just liveness

Turning this into practice means giving your monitor a second threshold:

• Set a response-time alert at "degraded," well below "dead." If your homepage normally answers in 400ms, an alert at 2–3 seconds sustained across several consecutive checks catches every mechanism above with time to act. Require the condition to persist — one slow sample is internet weather; five in a row is a trend.
• Base thresholds on your baseline, not a universal number. An API that normally answers in 80ms is deeply wrong at 1.5s; a report-generation endpoint might be fine at 4s. A week of monitoring history tells you what normal looks like; alert on departures from it.
• Watch trends between alerts. A response-time graph drifting from 300ms to 700ms over a month never crosses an alert line, but it's telling you something — about data growth, a missing index, or traffic outgrowing a server. Slow drift is capacity planning; fast drift is an incident.

Measure TTFB, from the outside

For monitoring purposes, the highest-signal number is time to first byte — how long from request until the server starts answering. It isolates your stack (network in, TLS, application logic, database, rendering the response) from page weight and frontend concerns, which makes it the number that moves when the backend is sick. You can decompose it yourself:

curl -s -o /dev/null -w \
'dns        %{time_namelookup}\nconnect    %{time_connect}\ntls        %{time_appconnect}\nttfb       %{time_starttransfer}\ntotal      %{time_total}\n' \
https://yoursite.com/

A healthy site might show TTFB a few hundred milliseconds above the TLS handshake time; a site entering the connection-pool spiral shows dns/connect/tls unchanged and TTFB climbing — which tells you it's the application, not the network, before you've logged into anything.

Two rules make the measurement meaningful:

• Measure from outside your network. Localhost TTFB skips DNS, real network paths and TLS setup — the visitor's experience includes all three. External measurement is the only honest kind.
• Measure continuously, not when curious. A single number is trivia; the same number every minute for six months is a baseline, a trend detector and an early-warning system.

Redefining "up"

The healthiest mental shift is to stop treating availability as a boolean. A site that's up-but-slow is partially down — losing some fraction of its visitors, revenue and search standing every minute, and quite possibly announcing a full outage in advance. Your monitoring should see it that way too.

CompleteStatus records response time on every single check, charts the trend for every monitor, and lets you alert on response-time thresholds exactly like downtime — same confirmation logic, same channels — with TTFB measured from outside, where your users are. See what it tracks, or create a free account and look at your own response-time graph after a week. Most teams find at least one surprise in it — better to meet that surprise on a graph than in an incident.