Guide
What causes a 500 error (and what to do)
“Internal Server Error” in plain English — what broke, whose fault it is, and your next steps.
Published
A 500 Internal Server Error means the website's server hit a problem it couldn't handle while building your page. It is a fault on the site's end, not something you did — refreshing or clearing your cache usually won't fix it. The common causes are a bug in the site's code, a failed database or API connection, a server misconfiguration, running out of memory, or a bad recent deploy. If it's your site, the real error is waiting in your server logs. If you're just a visitor, wait a moment and retry, then let the site owner know if it persists.
What “500” actually means
Every web response carries a status code. Roughly: 2xx means success, 3xx is a redirect, 4xx means something was wrong with the request (a 404 not found, a 403 forbidden), and 5xx means the server itself failed. A 500 is the generic member of that last family: “something broke and we can't be more specific.”
Its close relatives narrow it down. A 502 (bad gateway) means one server got a broken answer from another behind it; a 503 (service unavailable) usually means overloaded or in maintenance; a 504 (gateway timeout) means a backend took too long to respond. All of them are the server's side of the fence, not yours.
The usual causes
- Application code errors — an unhandled exception in the site's code crashes the request mid-render.
- A backend that isn't answering — the database, cache, or an external API the page depends on is down or refusing connections.
- Server or configuration mistakes — a broken rewrite rule, wrong file permissions, or a misconfigured runtime (PHP, Node, etc.).
- Resource exhaustion — out of memory, out of disk, or too many open connections under load.
- A recent change — a deploy, dependency upgrade, or plugin update that worked in testing but not in production.
If it's your website: what to do
Work from the most-likely-to-help to the least:
- Read the server and application logs first. A 500 is deliberately vague in the browser; the specific error — the stack trace, the failed query — is in the logs.
- Look at what changed last. Most 500s that appear out of nowhere trace back to the most recent deploy, config edit, or update.
- Check the dependencies. Is the database reachable? Is the external API up? A page can be flawless and still 500 because something it calls is down.
- Reproduce it and confirm the status. Check the exact URL and confirm it really returns 500 (and not, say, a 503) — the code points you at the cause.
- Roll back if you can't fix it fast. Reverting the last change restores service while you investigate calmly.
If you're a visitor
There is nothing to fix on your end. Refresh once, wait a few minutes, and try again — transient 500s often clear on their own. Clearing your cache or switching browsers won't help, because the break is on the server. If it keeps happening, tell the site owner and mention roughly when you saw it; that timestamp helps them find it in the logs.
Catching 500s before your visitors do
The worst way to learn your site is throwing 500s is a customer email hours later. A check that reads the actual status code tells you immediately whether a URL is returning 200 or 500, and shows the redirect chain and headers alongside it so you can see where the request really ends up.