HTTP 500 — Internal Server Error

Server error responses (5xx) · Updated 2026-10-18

HTTP 500 is the server admitting something broke on its side: an unhandled exception, a failed assertion, a bug. The request was fine — the handling was not. Retrying the identical request usually reproduces it.

When 500 shows up

• Unhandled exceptions bubbling to the top of a web framework.
• Configuration or dependency errors discovered mid-request.

Mocking a 500 response

A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):

{
  "method": "GET",
  "path": "/api/data",
  "status": 500,
  "delay": 300,
  "enabled": true,
  "body": {
    "error": "internal_error",
    "traceId": "{{string.uuid}}"
  }
}

Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.

Frequently asked questions

What does HTTP 500 mean?
The server failed while processing an apparently valid request. Clients can do little except report it; server logs hold the real diagnosis.

How can I test a 500 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 500. The example configuration above returns this response after the listed delay, so the client exercises its 500 handling exactly as it would against a live server.

Related status codes

Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.