Users say "the site is down" when a spinner lasts too long. Engineers need a sharper split, because the playbooks diverge.
Down
The request fails: connection refused, timeout beyond your limit, TLS error, HTTP 5xx (depending on what you count), empty response when you required content. Availability monitors are built for this. Consensus across regions answers whether failure is global or local.
Slow
The request completes — eventually. TTFB is ugly. Pages load in eight seconds. APIs return 200 in four seconds. The product is usable for the patient and broken for everyone else.
Uptime-only tools can stay green through a slowdown. That is not a bug in uptime; it is a different product surface (APM, RUM, synthetic multi-step, latency thresholds).
How to triage quickly
- Does an external check fail hard, or succeed slowly?
- Is every region slow, or one path?
- Did a deploy, traffic spike, or dependency status page move in the last hour?
- Are errors elevated, or only duration?
Full down → availability incident, status page likely red or degraded.
Slow with 200s → performance incident; maybe degraded, rarely "down," unless your SLO says otherwise.
Paging
Page immediately for confirmed global unavailability.
For slowness, page when you have a threshold you meant to keep — p95 above X for Y minutes — not when one person on cafe Wi‑Fi complains.
If you only have uptime monitoring today, do not pretend it is APM. Use it for down. Add latency tooling when slow nights become the real customer complaint. Mixing the two into one red alarm is how on-call learns to ignore both.
