Degraded means WebCheck received a response, but it was meaningfully slower than the target’s recent successful baseline or was identified as an edge challenge. It is a warning about quality or access, not the same thing as a failed request.
How slow responses are identified
WebCheck needs at least three previous passed runs before it compares timing against a baseline. A response becomes degraded when total duration is more than 1.5 times the median of the recent successful runs, with a 100 ms minimum floor, or when time to first byte crosses the corresponding 1.5 times median and 50 ms floor.
What degraded does to uptime
Passed and degraded runs count as available for uptime calculations. A degraded run does not open or increment a normal outage incident. Repeated degradation can still reveal a performance problem worth investigating.
Practical examples
- A page responds successfully after a database slowdown: degraded may be more accurate than failed.
- A CDN serves a managed challenge instead of the page: WebCheck records an edge warning rather than claiming the origin is down.
- A response is slow only once before enough history exists: the run may remain passed because there is not yet a reliable baseline.
What to do next
Compare the response-time history with recent deployments, application load, database timing, third-party dependencies and CDN events. Re-run the check and look for whether the warning persists.