HTTP 500 Internal Server Error – Free, Online, Private

What HTTP 500 means

500 is the general server failure. Something threw, an invariant broke, or the server otherwise could not produce a real response. The client cannot fix the request by editing it, except by luck. The body should be a generic message. A stack trace in a 500 is an information leak. Logs on the server are where the detail belongs, with a request id the client can quote.

500 Internal Server Error belongs to the 5xx server error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 500

When you see HTTP 500 Internal Server Error, stop on that exact status line. 500 Internal Server Error means the server hit an unexpected condition and could not finish. The trace that usually produces it: An unhandled exception escaped the handler. The 5xx server error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 500 when you failed and no more specific 5xx fits. Use 503 if you are temporarily refusing traffic. Use 502 or 504 if you are a gateway and the upstream failed or timed out. Do not return 500 for a validation error. That trains clients to retry bad data. Do not return 200 with an error string.

How to fix HTTP 500

To fix HTTP 500, change the condition that made the server choose Internal Server Error. Show a generic failure. Retry an idempotent request with backoff. For POST, retry only if you have an idempotency key or you know the operation did not start. Quote the request id if you contact support. Backoff, and only when the method is safe or idempotent. A tight retry loop turns a bug into a traffic spike. If the log line is a different code, leave this page. The mix-up people make with 500 is this one: 400 is the client's malformed request. 503 is a deliberate 'not now'. 502 is a bad upstream. 500 is this server failing unexpectedly.

• A null dereference on a path nobody tested.
• The error body included a stack trace and a connection string.
• A client retried POST blindly and duplicated a write that had actually succeeded before the crash.

An access log that only stores 500 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 500 Internal Server ErrorHTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error":"internal","requestId":"9f2"}

The request id is the useful field. The operator looks it up. The user sees a short apology. Retrying a GET is reasonable. Retrying a POST is how you double-charge if the failure happened after the side effect. Idempotency keys exist for that reason.

What the client should do

Show a generic failure. Retry an idempotent request with backoff. For POST, retry only if you have an idempotency key or you know the operation did not start. Quote the request id if you contact support.

Do not cache 500 as the representation. A stored 500 outage continues after the server has recovered.

Backoff, and only when the method is safe or idempotent. A tight retry loop turns a bug into a traffic spike.

Codes people confuse with HTTP 500

400 is the client's malformed request. 503 is a deliberate 'not now'. 502 is a bad upstream. 500 is this server failing unexpectedly.