Is 500 the same as 502 or 503?

No. RFC 9110 defines 500 as the origin hitting an unexpected condition in its own code. 502 means a gateway got an invalid upstream response, and 503 means the service is intentionally or temporarily unavailable.

Why doesn't the 500 page tell me what's wrong?

By design. 500 is the generic catch-all for when the server has no more specific status code. The real cause is in the server or application logs, not the response.

Can a 500 be intermittent?

Yes. Unhandled exceptions on specific inputs, memory exhaustion under load, or a flaky database connection produce 500s that come and go.

Views: 12

500 Internal Server Error Checklist

500 Internal Server Error? Separate an application crash from a gateway fault in 3 checks: final status code, origin reachability, response path. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The final response code for the site is 500 Internal Server Error.

Symptoms

HTTP Check shows a final status code of 500.
The page returns a generic error with no detail about the cause.
The failure may be constant, tied to specific routes, or appear only under load.

What 500 Actually Means

RFC 9110 (§15.6.1) defines 500 as “the server encountered an unexpected condition that prevented it from fulfilling the request.” It’s the catch-all the origin returns when it has no more specific 5xx code to offer. The distinction that matters: 500 is the application’s own code failing, while 502, 503, and 504 involve a gateway or proxy in front of it. A 500 means the request reached the application and the application broke.

That’s why the page is useless and the logs are everything. The server is deliberately hiding the stack trace from the public.

Top 3 Causes

An unhandled application exception - Code threw an error the framework didn’t catch: a null reference, a failed query, a bad type. The most common 500 by far.
Server or environment misconfiguration - A broken .htaccess, wrong file permissions, a missing module or environment variable, or a failed deploy left the app unable to start a request cleanly.
Resource exhaustion - The process ran out of memory, hit a connection-pool limit, or exhausted file descriptors, so requests die mid-handling.

Diagnose with DechoNet

HTTP Check to confirm the final code is truly 500 and not a gateway 502/503/504.
Port Check to verify the origin is actually accepting connections, ruling out a dead process masquerading as a 500.
DNS Lookup to confirm traffic is reaching the intended origin and not a stale or wrong host.

Resolution Checklist

Open the server and application error logs — the real cause is there, not in the 500 page.
Reproduce against one specific URL; note whether it’s every route or just some.
Check the most recent deploy or config change and roll back to test.
Verify file permissions, required modules, and environment variables the app needs to start.
Watch memory, database connections, and file-descriptor limits under load.
Re-run HTTP Check and confirm the final response is no longer 500.

When to Escalate

Escalate to the application owner when logs show an exception in business logic rather than infrastructure.
If 500s appear only under load, investigate scaling, connection pools, and resource limits with the platform team.