A 5xx response means the server-side application, gateway or upstream service reported a failure. The status code identifies the response class, while WebCheck history and your service logs provide the investigation trail.
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.