Is 500 my fault as a visitor?

Usually not—it's a server-side bug or outage. Retry later and report if it persists.

500 is often the origin app crashing; 502 is often a proxy getting a bad response from upstream.

Should I expose details in the response?

No in production—return a generic page and log details server-side only.

Error fix

The server hit an unexpected failure while handling the request—check application and dependency logs.

Start here first. Step 1 fixes most cases—then work down the list.

Why this works

These steps work because it clears stale cached state that can cause the same request to fail repeatedly.

500 indicates a failure on the server side, not a bad URL format. The response body may be generic; logs hold the real exception.

Unhandled exceptions
Null references, bad assumptions, or missing env vars in application code.
Upstream failures
Database timeouts, crashed workers, or misconfigured reverse proxies.

Find the stack trace
1. Open your hosting logs or APM and reproduce once with a single request.
2. Trace the failing layer: app server, DB, cache, or external API.
3. Deploy a minimal fix and add monitoring for the same error signature.

Also see: 500 — browse the HTTP status hub.

Is 500 my fault as a visitor?: Usually not—it's a server-side bug or outage. Retry later and report if it persists.
500 vs 502?: 500 is often the origin app crashing; 502 is often a proxy getting a bad response from upstream.
Should I expose details in the response?: No in production—return a generic page and log details server-side only.

Still stuck? Try these related fixes next.

Tweak the message and run again—we'll match an existing fix or generate a new page.

Original error message

500 Internal Server Error