A 5xx response usually means the application, gateway or upstream service reported a server-side failure. WebCheck marks it Failed when it falls outside the target's expected status range, which defaults to 200–399. The code identifies the response class; your service logs help find the cause.
What each status usually indicates
- 500: the application reported an internal server error.
- 502: a gateway or proxy received an invalid upstream response.
- 503: the service is unavailable or in maintenance mode.
- 504: a gateway timed out waiting for an upstream service.
Follow the evidence
Open the failing run and record the target URL, HTTP status, timing, final URL, redirect count and any bounded evidence. Then compare the first failure with the last successful run and the application, proxy, load-balancer and deployment logs.
Practical examples
- A deployment exception may produce 500 from the application.
- A stopped upstream process may produce 502 from a reverse proxy.
- A planned maintenance page may correctly return 503 for a short period.
- An overloaded backend may cause 504 when the proxy timeout expires.
Confirm recovery
After correcting the underlying problem, re-run the check or wait for the scheduled run. Confirm that the response returns to the expected range and that any confirmed incident follows its recovery policy.