A 500 Internal Server Error means the server received your request, started processing it, and its own code failed in a way it did not expect. It is the most generic error in the 5xx family, the catch-all a server returns when something went wrong and it has nothing more specific to say.
The one-line definition ¶
500 Internal Server Error is an HTTP response status code indicating the server encountered an unexpected condition that prevented it from fulfilling the request.
Per RFC 9110, 500 is the generic server-side error, used when no other 5xx code fits. In practice it almost always means an unhandled exception: the application threw an error nobody caught, and the framework or web server converted the crash into this response. That detail matters for diagnosis, because it tells you the request made it all the way into real application code before anything broke. The network worked, the proxy worked, the server was accepting connections. The code itself failed.
500 vs 502, 503, and 504 ¶
The four common 5xx codes describe four different failure points, and knowing which one you got narrows the search immediately.
| Code | What failed | Typical cause |
|---|---|---|
| 500 | The application itself | Unhandled exception while processing the request |
| 502 | The backend, as seen by a proxy | Reverse proxy got an invalid or empty response from upstream |
| 503 | Nothing yet, the server is refusing work | Overload, maintenance, deliberate load shedding |
| 504 | The backend, by silence | Reverse proxy gave up waiting for upstream to answer |
A 502 or a 504 means the proxy layer is fine but the thing behind it is broken or unreachable. A 503 means the server is alive and deliberately declining requests. A 500 is different from all three: the server accepted the request, ran its code, and the code crashed. If you operate the site, a 500 points you at your application logs. The other three point you at infrastructure.
Common causes of a 500 ¶
- Bad deploy. New code shipped with a bug that only appears under production data or production configuration. If 500s started within minutes of a release, the release is the prime suspect.
- Unhandled exception. A null value, an unexpected input, an edge case nobody wrote a handler for. The framework catches the crash and emits a generic 500 rather than exposing the stack trace.
- Database connection failure. The application is up but cannot reach its database, the connection pool is exhausted, or a query fails mid-request. Many frameworks surface this as a 500 on every page that touches the database.
- Configuration or environment error. A missing environment variable, a rotated credential nobody updated, a wrong file permission, a config file that parses in staging but not in production.
- Plugin errors on WordPress. A fatal PHP error in a plugin or theme, usually right after an update, is the classic WordPress 500. A corrupted
.htaccessfile or an exhausted PHP memory limit produces the same symptom.
Why 500s often hit one endpoint, not the whole site ¶
Because a 500 is a code failure, it follows code paths, not servers. The homepage renders from a template and a cache and works fine. The checkout endpoint calls a payment library with a value the new deploy changed, and every checkout returns 500. Users report "the site is broken" while the front page, and any monitor pointed at the front page, looks perfectly healthy.
This is the sharpest practical difference from a 502 or 504, which usually take out everything behind the affected proxy at once. With 500s, the blast radius is whatever the broken code path serves: one route, one form, one API endpoint. It also means an uptime check of the root URL can pass all day while the part of the site people actually use is failing. If a specific action fails for you, test that exact URL, not just the domain.
The probe pattern helps here too. When a page returns 500 to all four of isitdown.io's probe methods, the application is failing for everyone who hits that path, regardless of browser or client. A mixed result, where some methods pass and some fail, points away from a 500 and toward the site blocking or mishandling a particular request type instead.
What you can do as a user ¶
Very little, honestly. The failure is inside someone else's code, and nothing on your machine caused it or can fix it.
- Refresh once. If the 500 came from a single crashed worker or a deploy in progress, a second request may land on a healthy instance. Refresh once, not repeatedly. Hammering an erroring endpoint adds load and helps nobody.
- Check whether it is down for everyone. Run the domain through a multi-method check, or follow the 60-second diagnostic. Consistent 500s across all probe methods confirm the problem is on their side.
- Come back later. Most 500 incidents end with a rollback or a hotfix. If the action involved money, an order, or a form submission, do not resubmit blindly, check whether the first attempt went through before trying again.
What to check as a site owner ¶
- Error logs first. A 500 always leaves a stack trace somewhere: application logs, the web server's error log, or your error-tracking service. The trace usually names the exact file and line. Do not guess when the log can tell you.
- Recent deploys. Correlate the first 500 with your release timeline. Most application-level incidents trace back to a change someone made, code, config, or infrastructure, shortly before the errors began.
- Roll back. If the timing implicates a deploy, roll it back before debugging further. Reverting is almost always faster than diagnosing forward under pressure, and you can study the bug calmly once users are unblocked.
- Dependencies and environment. If no deploy is implicated, check database connectivity, connection pool usage, disk space, and any credentials or environment variables that could have rotated or expired.
- On WordPress. Rename the plugins directory to disable all plugins at once, switch to a default theme, regenerate
.htaccess, and raise the PHP memory limit. Re-enable plugins one at a time to find the culprit.
To hear about the next one before your users do, put a monitor on the affected URL. isitdown.io probes every 5 minutes with 4 independent methods, opens an incident after 2 consecutive failed probes, and can notify you by email or fire a webhook with a JSON payload on every status transition.
FAQ ¶
Is a 500 error my fault as a visitor?
No. If a request is malformed or unauthorized, a correctly built server answers with a 4xx code. Returning 500 means the server's own code failed to handle what you sent, and that is the server's bug by definition.
How long do 500 errors usually last?
There is no standard duration. A bad deploy that gets rolled back can be over in minutes. A database failure or a subtle config error can persist until someone reads the logs. If a 500 lasts more than 15-30 minutes on a major service, check their status page for an acknowledged incident.
Should automated clients retry on a 500?
Cautiously. Unlike a 503, a 500 carries no Retry-After hint and no promise the condition is temporary. One or two retries with backoff are reasonable for idempotent requests. Never blindly retry non-idempotent requests such as payments, because the server may have partially processed the first attempt before it crashed.