Quick Answer: Degraded performance in uptime monitoring means your service is reachable and returning successful responses, but not performing well enough for real users. The site might return 200 OK while taking 8 seconds to load. Basic uptime checks mark that as "up." A degraded status catches slow responses, rising latency versus baseline, and partial failures before they become full outages.
What does degraded performance actually mean?
Most uptime monitors answer one question: did the server respond with an acceptable status code? If your homepage returns 200 within the timeout, the monitor reports up. Users experience something different: spinners, stale data, checkout buttons that take three taps, search results that never finish loading.
Degraded performance sits between healthy and down. The service is technically available. It is not meeting the level of performance your users expect or your SLA implies. Azure Resource Health uses the same framing: degraded means "detected a loss in performance, although still available for use." Statuspage treats degraded separately from major outage because customers can still use the product, just painfully.
For HTTP and TCP monitoring, the signals look like this:
| Status | What the probe sees | What users feel |
|---|---|---|
| Up | Fast response, expected status | Normal experience |
| Degraded | 200 OK but slow, or quality issue | Sluggish, flaky, "something feels off" |
| Down | Timeout, connection error, 5xx | Cannot use the product |
The dangerous gap is the degraded zone. Your on-call engineer sleeps. Support tickets trickle in. Database CPU climbs. By the time the monitor flips to down, you are already in incident mode.
Why do basic uptime checks miss degraded performance?
A probe sends GET / every 60 seconds. The load balancer returns 200 in 6 seconds. The monitor logs success. Meanwhile:
- Your database connection pool is exhausted but still answering
- A cache layer failed and every request hits Postgres
- One app server in the pool is unhealthy but others absorb traffic
- A third-party API adds 4 seconds to every request without failing outright
None of these produce error codes. All of them destroy user experience.
Single URL checks make this worse. Your marketing site loads in 200ms while /api/checkout hangs for 30 seconds. Homepage monitor stays green.
Static timeouts create the opposite problem. Set a 10-second timeout and a 7-second response passes every check. Set a 2-second timeout and you page during every traffic spike. You need context: is 800ms slow for this endpoint, or normal?
No baseline comparison means you cannot tell if today is unusual. Response time of 1.2 seconds might be fine for a dashboard that aggregates ten data sources. It is a crisis for a login endpoint that normally responds in 60ms.
How do I detect degraded performance before users complain?
Track latency on every successful check. Do not only record failures. Store response time per check run and compare against a rolling baseline. Overwatch marks HTTP and TCP checks as degraded when latency on successful responses crosses a threshold relative to the 30-day moving average. A sudden 5x spike on an endpoint that was stable for weeks is worth a warning, even at 200 OK.
Set per-endpoint thresholds, not one global number. Your health check should have a tight budget. Your PDF export endpoint should have a loose one. Tune each monitor to its own normal behavior instead of copying settings from your homepage check.
Monitor the paths users actually take. Add separate checks for login, search, payment, and your internal health route. Degradation often appears on one critical path while the homepage looks fine.
Validate response content, not just status codes. A 200 response with an empty JSON body or a "service unavailable" string in the HTML is degraded quality even when the status code passes. Keyword and body checks catch wrong-data scenarios that latency alone misses.
Route degraded alerts to a warning channel. Down pages on-call. Degraded posts to #alerts-warning or a Slack channel the team checks during business hours. The goal is early investigation, not a 3am wake-up for a latency spike that resolves in five minutes.
When should I page on-call vs send a degraded warning?
Use severity tiers:
- Down (failed check, error status, timeout): page immediately. Customer impact is confirmed.
- Degraded (slow but successful, quality warning): notify warning channel. Investigate within hours, not seconds.
- Up (within baseline): no action.
If degraded alerts fire constantly, widen the baseline multiplier or fix the underlying instability. A warning channel that fires 50 times a day gets muted just like a noisy paging policy.
Degraded status also helps status pages. Showing "degraded performance" on checkout while the homepage stays operational gives customers accurate context. A green status page during slow checkout erodes trust faster than a yellow banner that says you are investigating latency.
Frequently Asked Questions
What is degraded performance in uptime monitoring?
Degraded performance means a service is technically available (usually returning a successful HTTP status) but not performing acceptably. Common signals include response times far above baseline, intermittent timeouts that recover, or correct status codes with wrong or incomplete content. Uptime tools that only check for errors miss this state entirely.
How is degraded different from down in monitoring?
Down means the check failed: connection error, timeout, or an unexpected status code. Degraded means the check succeeded but crossed a performance or quality threshold. Down should page on-call immediately. Degraded should notify a lower-priority channel so the team can investigate before customers flood support.
Should I alert on degraded performance?
Yes, but not the same way you alert on outages. Route degraded alerts to a warning channel like #alerts-warning instead of paging on-call. Degraded status is early signal: database load climbing, cache misses increasing, or a deploy introducing latency. Acting on degraded alerts often prevents the next hard outage.
What response time threshold should I use for degraded alerts?
Avoid a single static millisecond limit for every endpoint. Compare current latency to that endpoint's own baseline. Many teams alert when response time exceeds 2x to 3x the 30-day average for successful checks. A search API that normally responds in 80ms should not share the same threshold as a report export that normally takes 4 seconds.
Why does my uptime monitor show up when the site feels slow?
Basic uptime checks only verify that the server returned a non-error status code within a timeout window. A page that loads in 12 seconds with a 200 OK still passes. To catch slowness, add response time tracking against a baseline, content validation for critical fields, and separate monitors on the slow endpoints users actually hit.
Green monitors do not mean happy users. Overwatch tracks response times on every check, marks endpoints as degraded when latency spikes against a 30-day baseline, and routes warnings to Slack, Discord, Teams, email, or any webhook without waking on-call for every blip. Catch slow responses while they are still warnings, not outages. Get started free →