HTTP 500 through 599 responses indicate that a server or intermediary could not complete an otherwise valid request. Uptime Basics labels an unaccepted response in this range Server error.
The responding component may be the application, web server, CDN, reverse proxy, load balancer, API gateway, or hosting provider. The HTTP code and response timing help identify which layer failed.
Common server errors
| Code | Common meaning | First places to check |
|---|---|---|
| 500 | Internal server error | Application exceptions, configuration, dependencies, and deployment logs |
| 501 | Not implemented | Unsupported request method or server capability |
| 502 | Bad gateway | Proxy-to-origin connection, upstream process, DNS, and TLS |
| 503 | Service unavailable | Maintenance, overload, health checks, capacity, or dependency failure |
| 504 | Gateway timeout | Slow origin, database, dependency, queue, or network path |
Other 5xx codes can be provider-specific. Use the component's documentation and logs rather than assuming every 5xx has the same cause.
Investigate the failed time
- Open Detailed Logs and note the code, latency, timestamp, and regional Confirmation.
- Open the related incident when the monitor reached a confirmed Down state.
- Review deployments, configuration changes, scaling events, and maintenance.
- Compare CDN, load balancer, web server, application, database, and dependency logs.
- Test the exact monitored path from an independent network.
One 5xx row does not automatically open an incident. Uptime Basics requires the normal consecutive and regional confirmation before changing availability to Down.
Use regional evidence
If all regions receive the same 5xx response, the issue is likely at a shared application, origin, or global edge layer. If only one region fails, investigate regional CDN behavior, routing, origin selection, or provider capacity.
A website loading for you after the event does not invalidate the saved result. Short server failures can recover before a manual browser test.
Check the request method
GET is the default and most compatible request method. Paid monitors using HEAD can retry with GET after HTTP 500 or 501 when enough of the same timeout budget remains.
If a route handles GET correctly but rejects or breaks on HEAD, save GET as the monitor method. Do not accept a persistent 500 only to avoid correcting method handling.
Should you accept a 5xx response?
For a normal website or health endpoint, a 5xx response should remain a failure. Accepting it can hide a real outage.
An accepted 5xx code is appropriate only when a specialized endpoint deliberately uses that exact response as its documented healthy result. Once accepted, future responses with that code count as Up and no Server error diagnosis is recorded.
During a long outage
Keep the monitor active while repairing the service so recovery is detected and incident history remains complete. Automatic protections can reduce repeated work and notification volume during a prolonged failure without rewriting the configured interval.
When to contact Support
Contact Support if the exact public endpoint is healthy from independent networks and your infrastructure logs do not show the 5xx response recorded by Uptime Basics.
Include the monitor name, URL, code, timestamps, response time, affected regions, and relevant provider layer. Do not include passwords, authorization headers, cookies, database credentials, private keys, or full stack traces containing secrets.