HTTP 500 Internal Server Error

The server failed and cannot say anything more useful. Nothing about the request needs to be wrong.

Defined in RFC 9110 §15.6.1 — 500 Internal Server Error · MDN reference

Where you meet HTTP 500 in production

An unhandled exception, a null dereference, a failed database call with no catch around it — the code that means the server hit something it did not plan for.

Why you would test it

Nearly impossible to provoke on demand against a healthy API, which is why retry, fallback and error-reporting paths so often ship untested.

What your client should do about a 500

A single retry is defensible for an idempotent request. For anything that writes, retrying a 500 risks doing the work twice, because a 500 does not tell you whether the operation completed before the failure — send an Idempotency-Key so the retry is safe, or do not retry at all.

500 versus the codes it gets confused with

Endpoints that return 500

2 endpoints in this playground answer with 500. Every one is free, needs no signup, and can be called from the browser or with curl.

Questions about HTTP 500

Should a 500 body include the stack trace?
Never in production. A correlation id the caller can quote to support is the useful thing to return.
Is it safe to retry a 500?
Only if the request is idempotent, or carries an idempotency key. Otherwise a retry can duplicate a completed write.

Other server error codes

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated