Website Downtime vs Slow Website: What’s the Difference?
A site can be “up†but painfully slow. Or it can be fast for some users and broken for others. This guide explains how to distinguish downtime from degraded performance, and how to monitor both.
Short definition
Downtime means requests fail. A slow site means requests succeed but take too long. Both harm revenue, but they’re detected and handled differently.
The key differences
Downtime
Requests fail (5xx errors, DNS failures, or timeouts). Users can’t complete key actions.
Slow performance
Requests succeed but exceed your latency thresholds. Users can complete actions, but frustration and drop‑off increase.
Impact scope
Downtime is often total or partial failure. Slowness can be caused by backend or front‑end issues and may affect some regions more.
Monitoring approach
Downtime is detected by success/failure checks. Slowness requires latency tracking and performance thresholds.
How to classify incidents
- If requests consistently fail, classify as downtime.
- If requests succeed but exceed user‑tolerable time, classify as degraded.
- If only one region or ISP is affected, classify as partial outage.
- If an API fails but the homepage loads, classify as partial outage.
Recommended thresholds
Timeout threshold
Set a timeout that matches user expectations (often 5–10 seconds for basic pages). If requests exceed it, treat it as a failure.
Latency thresholds
Track median and 95th percentile latency. Alert if sustained latency exceeds your acceptable window.
What to monitor
Availability checks
HTTP status, DNS resolution, TLS handshake, and connection errors.
Performance checks
Response time, synthetic transactions, and critical path latency.
Business‑critical endpoints
Checkout, login, and booking should be monitored separately.
Multi‑location checks
Confirm from multiple regions to distinguish real failures from local network issues.
Want to catch both downtime and slowdowns?
Start a 30-day free trial and get alerted the moment performance degrades.
FAQ
Is a slow site considered downtime?
Not always. Slowness is usually “degraded performance,†but severe slowness can feel like downtime to users.
What’s a good timeout for a basic website?
Many teams use 5–10 seconds, but set a threshold based on your users’ expectations and page complexity.
Can I get alerts for slowness only?
Yes. Configure latency‑based alerts in addition to downtime alerts.
Why do some users report slowness while others don’t?
Regional routing, ISP congestion, or CDN edge issues can cause inconsistent performance.
Sources
Google SRE Book: availability as successful requests; latency as a core performance metric.
RFC 7231: 5xx errors indicate server failures; 408 indicates request timeout.
Cloudflare learning docs: latency and performance impacts across networks and regions.