HTTP status code
Internal Server Error
The server hit an unexpected condition and could not complete the request.
The generic server-side error. Something threw an exception that nothing caught. A 500 tells you the failure is on the server and nothing more — the detail is in your logs, deliberately not in the response.
Go straight to the application logs — the response will never tell you anything useful, by design. If it started at a deploy, compare environment variables between the working and broken release; a missing variable is the single most common cause of a deploy-triggered 500. If it is intermittent, suspect connection-pool exhaustion or memory limits under load.
A 500 means your server is up and answering — it is your application that is broken. A ping or TCP check will look perfectly healthy throughout, which is exactly why HTTP-level monitoring matters.
Monitor for 500 responses freeA 500 comes from your application: it ran and threw. A 502 comes from a proxy in front of your application: it could not get a usable response at all. For a 500 read your application logs; for a 502 check whether the application is running.
Deliberately. Error detail can expose file paths, library versions, and query structure, all useful to an attacker. The detail goes to your logs instead.
Frequently, and those are the hardest to catch. Connection-pool exhaustion, memory pressure, and race conditions all produce 500s only under particular load. Continuous monitoring catches the pattern that manual testing misses.
Pingura checks your endpoints from five regions and alerts on the status code, not just reachability.
Get Started Free