HTTP Status Code 500: What It Means and What to Do

HTTP status code 500, called Internal Server Error, means the website's server hit a problem it could not handle while processing your request. The error is on the website's side, not on your computer, your browser, or your internet connection.

An HTTP status code is the short numeric answer a server sends with every page it returns. Codes in the five hundreds all mean server failure, so a 500 is the server admitting something broke without saying what.

What causes an HTTP 500 status code?

A 500 is deliberately vague. Servers are configured to hide internal details from visitors, because those details would help an attacker. Behind the generic message, the usual causes are ordinary software failures.

• A bug in the site's code that throws an unhandled error on a particular page or action.
• A database that is unreachable, overloaded, or returning an error to the application.
• A broken or half-finished deployment, where new code is live but something it depends on is not.
• A configuration mistake on the server, such as a bad rewrite rule or a wrong file permission.
• A plugin, extension, or third-party integration that failed and took the request down with it.
• Resource exhaustion, where the server ran out of memory, processes, or disk space mid-request.

Nothing you type or click causes a 500 in the sense of being your fault. Certain inputs can trigger a bug that was already there, but a correctly built site returns a clear message instead of collapsing.

What should I do when a site returns a 500 error?

As a visitor, your options are limited by design, but a few of them work often enough to be worth thirty seconds.

1. Reload the page once. Transient 500s from a momentary overload clear immediately.
2. Wait a few minutes and try again. Deployment-related failures are often fixed quickly.
3. Open the same page in a private window, which sends no cached data and no old session cookie.
4. Clear cookies for that site only, since a corrupted session can trigger an error on one account while everyone else is fine.
5. Try a different browser or your phone on mobile data, which tells you whether the failure follows you.
6. Check whether the site is down for everyone using an outage-report service or the company's status posts.

If the error appears only on one page, or only after you submit a particular form, note that precisely. That detail is exactly what the site's own team needs.

Was my payment or form submission processed despite the 500?

Sometimes yes, which is why this deserves care. A 500 can occur after the server already saved your data but before it managed to render the confirmation page.

• Do not immediately resubmit a payment. Check your bank or card app first for a pending charge.
• Check your email for a confirmation message, which is often sent before the page finishes rendering.
• Sign in and look at your order history, ticket list, or account activity before trying again.
• If you cannot tell, contact the company and describe what you did and when, rather than repeating the action.

Duplicate orders and double charges are far more painful to unwind than a short wait to confirm.

How is a 500 error different from 502, 503, and 504?

All four are server-side, but they describe different failures, and knowing which one you have narrows the cause considerably.

• 500 Internal Server Error: the application itself failed while producing the response.
• 502 Bad Gateway: a server acting as a middleman received an invalid response from the server behind it.
• 503 Service Unavailable: the server is reachable but is refusing work, typically due to maintenance or overload.
• 504 Gateway Timeout: a middleman waited for the server behind it and gave up.

A visitor's practical response is the same for all four: wait and retry. For anyone running the site, they point at different layers, with 500 pointing at the application code and the others pointing at the path in front of it.

Is a 500 error dangerous or a sign of hacking?

By itself, a 500 is a malfunction, not a breach. Most of them are bugs, deployments, and overloaded databases.

Two cautions still apply. If a 500 page displays file paths, code fragments, or database messages, the site is leaking internal details that should be hidden, which is a genuine misconfiguration worth reporting. And if you receive an email or message claiming a site error requires you to confirm your password or card details, treat it as a phishing attempt: error pages never ask for credentials.

I run the website. How do I diagnose a 500 error?

Work from the record the server already made rather than from the browser. The visible page tells you nothing; the logs tell you everything.

1. Open the server error log and the application log for the exact timestamp of the failed request. The stack trace or error line is the actual answer.
2. Establish scope: one page, one user, one region, or everything. Scope points at code, data, cache, or infrastructure respectively.
3. Check what changed recently, including deployments, dependency updates, configuration edits, plugin updates, and certificate or credential rotations.
4. Check the dependencies: database connectivity, connection pool limits, cache availability, disk space, memory, and file permissions.
5. Reproduce the request deliberately in a staging environment with detailed errors enabled, never on the live site.
6. Roll back the last change if the timing matches, then investigate with the pressure off.

Keep detailed error output turned off for visitors permanently, and return a plain error page with a reference identifier that appears in your logs. That gives support something to search for without exposing anything.