Downtime vs Degraded Performance: What's the Difference and Why It Matters

Your server returns a 200 OK, but the page takes 18 seconds to load. Your API responds, but with empty data. Your checkout page loads, but the payment form never renders.

Technically up. Functionally down.

Understanding this distinction isn't academic. It affects your SLAs, your monitoring strategy, your incident response, and ultimately how your users experience your product.

What is Downtime?

The Simple Case

Downtime is straightforward: your service is completely unavailable. Users get connection errors, timeout messages, or HTTP 5xx responses. Nothing works.

Common causes of full downtime:

• Server crash or hardware failure
• Network outage
• DNS resolution failure
• Expired SSL certificate (browsers block access)
• Catastrophic deployment failure
• Database server completely down
• DDoS attack overwhelming all resources

Downtime is easy to detect. A simple HTTP check that expects a 200 response will catch it. If the server doesn't respond or returns an error code, it's down.

The clarity is almost a feature: everyone agrees the site is down, the problem is obvious, and the urgency is clear.

What is Degraded Performance?

The Harder Problem

Degraded performance is when your service is technically available but not functioning properly. It responds, but poorly. It loads, but slowly. It works, but partially.

Types of degradation:

Degradation is insidious because it's ambiguous. There's no clear moment where everything breaks — it slowly gets worse, or it only affects some users, or it only breaks certain features.

The Gray Zone: When "Up" Doesn't Mean "Working"

The Most Dangerous State

The gray zone is where most real incidents happen. Consider these scenarios:

In all these cases, traditional uptime monitoring reports "UP" with green checkmarks.

How Users Experience Each

Full downtime is dramatic but clear. Users see an error page, they know it's broken, they come back later. Some are annoyed but most understand that things break.

Degraded performance is worse for user trust because it's confusing:

• "Is it my connection or their site?"
• "It worked a minute ago, why not now?"
• "The page loaded but the button does nothing"
• "I submitted the form but nothing happened"

Users blame themselves first, then get frustrated, then leave. They're less likely to come back because the experience was confusing rather than clearly broken.

The data backs this up: a site that's completely down for 10 minutes causes less long-term damage than a site that's painfully slow for 2 hours. Users forgive outages more easily than they forgive unreliability.

From a support perspective, degradation generates more tickets than downtime. During downtime, one tweet or status page update covers it. During degradation, every user has a slightly different experience and a slightly different complaint.

Impact on SLAs and Uptime Calculations

This is where the distinction gets financially real.

Most SLAs define uptime as "the service responds with a non-error status code." By this definition, degraded performance isn't downtime. A 200 OK response that takes 30 seconds still counts as "up."

This creates a gap between what your SLA promises and what your users experience:

Two of these five scenarios are counted as "up" by most SLAs but are functionally broken for users.

If you're building your own SLA as a SaaS founder, consider including response time thresholds, not just availability. For example: "Service is considered available when it responds with a 2xx status code within 5 seconds." This aligns your SLA with actual user experience.

More on SLAs: SLA and Uptime Guarantees Explained

Why Traditional Monitoring Misses Degradation

Basic uptime monitoring does one thing: sends an HTTP request and checks if the response status is 2xx. If yes, the site is "up." This misses:

• Slow responses — a 200 that takes 20 seconds is still a 200
• Partial failures — the homepage works but checkout doesn't
• Content issues — the page loads but with wrong or missing data
• User flow breaks — login works but the session doesn't persist
• Third-party failures — your code works but Stripe/Auth0/CDN doesn't
• Regional issues — works from your monitoring location but not from others

To catch degradation, you need response time monitoring with thresholds, multi-step flow monitoring, content validation, multi-location checks, and real user experience correlation.

How to Monitor for Both

A complete monitoring strategy covers the full spectrum from total downtime to subtle degradation.

Incident Response: Different Problems, Different Playbooks

Downtime and degradation require different responses.

The key difference: downtime is binary and urgent. Degradation requires judgment.

Real-World Examples

These examples share a pattern: the most impactful incidents aren't binary up/down events. They're partial, ambiguous, and harder to detect.

Conclusion

The distinction between downtime and degraded performance isn't pedantic — it's practical.

Downtime is obvious, urgent, and easy to detect with basic monitoring. Degradation is subtle, often more damaging, and requires deeper monitoring to catch.

Most teams over-invest in downtime detection (which is the easier problem) and under-invest in degradation detection (which is the more common problem).

If your monitoring strategy only answers "Is the site up?" you're missing the question that matters more: "Is the site working well for users?"

The fix isn't complicated. Layer response time monitoring, flow monitoring, and visual checks on top of your existing uptime checks. Catch both ends of the spectrum.

Related reading: Causes of downtime • Downtime prevention • Downtime cost calculator • Monitoring frequency guide

Frequently Asked Questions