Skip to main content
performance monitoring anomaly detection

Website Slow but Not Down: Why Every Check Passes While Customers Wait

A website slow but not down passes every uptime check. Why monitors miss slowness, how to confirm it, and how to get alerted before customers complain.

FLAREWARDEN
FlareWarden Team
6 min read

The support ticket says the site is crawling. The monitoring dashboard says 100% up. Both are telling the truth, and that’s the problem. An uptime check asks exactly one question: did the server return a success response before the timeout? A page that answers in 8 seconds passes that test just as cleanly as one that answers in 200 milliseconds. Slow isn’t down, so nothing fires.

What Your Uptime Check Actually Measures

A standard HTTP check requests a URL, waits, and records two things: the status code and whether the response arrived in time. Timeouts are generous by design, because their job is to catch outages without crying wolf. Everything between “instant” and “timed out” reads as success.

Three more blind spots stack on top of that:

  • It checks one URL. Usually the homepage. Your homepage can be fast while the checkout API, search, or logged-in dashboard crawls. The check passes; the revenue path doesn’t.
  • It may never touch your origin. If your CDN serves the checked page from edge cache, the monitor measures the CDN’s speed, not your server’s. The origin can be drowning behind a healthy-looking cache.
  • It doesn’t run your front end. A ping sees first-byte and response time, not the 6 seconds of JavaScript and images your customer sits through. What a user calls “slow” often lives entirely after the part a check can see.

None of this means uptime checks are bad. They answer “is it reachable?” reliably and cheaply. The mistake is expecting that answer to cover “is it usable?”, which is a different question with different tooling.

First, Confirm and Measure the Slowness

“It feels slow” isn’t actionable, so put numbers on it. Google’s own thresholds are a sane yardstick: server response (time to first byte) should be under 0.8 seconds, with anything past 1.8 seconds rated poor, and the main content of a page should render in 2.5 seconds or less for 75% of visits.

The five-minute diagnosis:

  1. Time the server, not the page. curl -w "%{time_starttransfer}\n" -o /dev/null -s https://yoursite.com gives you first-byte time without browser noise. Run it a few times, and from a second location if you can; a VPN exit or a colleague’s connection will do.
  2. Separate one page from every page. If only checkout is slow, look at what checkout touches (payment APIs, sessions, the database). If everything is slow, look at the server and its resources.
  3. Check whether it’s peak-hours-only. Slowness that tracks your traffic curve points at capacity: connection pools, CPU, an underprovisioned database. Slowness at 3 a.m. points at background work like backups and batch jobs colliding.
  4. Run the front end once. PageSpeed Insights or your browser’s DevTools shows whether the delay is server time or the payload afterward: images, scripts, third-party tags.

The usual culprits behind up-but-slow: a database that grew past its indexes, third-party scripts and APIs dragging the page down with them, cache misses exposing a slow origin, and scheduled jobs quietly eating the server during business hours.

Slow Bleeds Money While Down Merely Burns It

Downtime is loud: alerts fire, people notice, someone fixes it. Slowness is quiet and lasts weeks. Deloitte’s Milliseconds Make Millions study measured what a 0.1-second mobile speed improvement did: retail conversions rose 8.4% and average order value 9.2%. The same math runs in reverse when you get slower. We’ve dug into the speed-and-revenue numbers before; the short version is that a website slow but not down is losing money in a way no uptime report will ever show.

Getting Told Automatically, Without the False Alarms

The obvious fix is a response-time threshold: alert me when checks take longer than 800 ms. Sometimes that’s enough, and plenty of tools offer it. But one static number has to survive your whole week, and most sites don’t have one normal speed. They have a quiet-Sunday normal and a Monday-peak normal, often a multiple of each other. Set the line low and peak hours page you daily until you mute it; set it high and it stays silent until things are already terrible. Most people tune it twice, get burned twice, and turn it off.

The approach we’ve landed on after running this trade-off across a real fleet: learn what normal looks like for each monitor at each hour of the week, and alert on sustained deviation from that instead of a fixed line. A check that’s 3× its own Tuesday-2-p.m. baseline is interesting; a single slow sample isn’t, so confirmation requires the deviation to persist across consecutive checks. FlareWarden ships this as learned response-time baselines (currently in beta, available on every plan including free): the chart marks suspect periods, confirmed events land in a log with observed-versus-expected numbers, and alerts stay opt-in so the feature informs rather than pages. Fair warning from the docs: baselines need about 3 days of history for a first expected range, so it’s a thing to set up before the slow week, not during it.

Whatever tool you use, the principle holds. Reachability and speed are separate signals; monitor both, and judge speed against the site’s own history rather than a number you guessed. A green uptime badge tells you customers can reach the slow page. It takes a second signal to tell you they’re waiting at it.

Key Takeaways

  • Uptime checks measure reachability, not experience — any response inside the timeout counts as up, so an 8-second page and a 200 ms page look identical
  • The blind spots compound — checks watch one URL, may hit CDN cache instead of your origin, and never execute the front end your users actually wait for
  • Put numbers on “slow” before debugging — first byte under 0.8 s and main content under 2.5 s for 75% of visits are Google’s yardsticks, and curl -w gets you a clean first-byte reading in seconds
  • Slowness has a bigger invoice than most outages — Deloitte measured 8.4% more retail conversions from a 0.1 s improvement, and the effect runs both directions
  • Static response-time thresholds mostly get muted — one number can’t fit both quiet Sundays and peak Mondays; baselines learned per hour of the week can
  • Set up degradation detection before you need it — learned baselines take a few days of history to calibrate

Want a second signal beyond the green badge? Start monitoring free with FlareWarden — 15 monitors with multi-region verification, and learned response-time baselines in beta on every plan.