Skip to content
WebAuditOS
Start free audit

Test your website now

Free, no card. We read only public pages.

Run free audit →

HTTP errors

What does 500 Internal Server Error mean, and how do you fix it?

A 500 means your application hit an error it did not handle. How to find the real cause in the logs, and why the error page must never show a stack trace.

500 Internal Server Error means the application received the request and failed while handling it, usually because of an unhandled exception, a failed database query or a missing configuration value. The response itself tells you almost nothing. The cause is in your server or application logs, at the time of the request.

Published · Last updated

By Michal Měřínský. Audit methodology.

What 500 Internal Server Error means

500 is the generic server-side error. The request reached your application, the application started handling it, and something went wrong that nobody planned for. It is deliberately vague: the specification uses it for any unexpected condition that prevented the server from fulfilling the request.

That vagueness is the point of the next sections. A 500 is a symptom. The useful information is never in the browser. It is in the logs.

If you are a visitor

A 500 is the site's problem, not yours. Reload once, since some 500s are transient. If you were submitting a form, check whether it went through before submitting again, because the action may have half-completed.

Why your own site returns 500, most likely first

  • An unhandled exception in your code, often on input nobody tested: an empty field, an unexpected character, a missing record.
  • A database error: a failed connection, a query against a column that does not exist yet because a migration did not run, or a timeout.
  • Missing configuration. An environment variable that exists locally but was never set in production is one of the most common causes on freshly deployed apps.
  • A third-party API call that fails and is not caught.
  • File permissions or a full disk, on servers you manage yourself.

How to fix it

Open the logs at the timestamp of the error and find the stack trace. On a platform like Vercel, Netlify, Railway or Render, that is the function or deployment log. On your own server, it is the application log and the web server error log.

Reproduce it with the same request:

curl -i https://example.com/the-failing-page
  • If the trace points at a missing variable, compare production environment variables with your local file, name by name.
  • If it points at the database, check that migrations ran on the production database, not just locally.
  • Fix the cause, then add handling for that class of input so a bad request returns a 4xx with a clear message instead of a 500.
  • Add error tracking so the next 500 reaches you before a user reports it.

Never fix a 500 by catching every exception and returning 200. The error is still there, and now neither you nor search engines can see it.

What the error page must not show

A default error page in development mode often prints the stack trace, file paths, framework version and sometimes configuration values. In production, that is information an attacker can use to target known vulnerabilities in your exact stack. Show a plain error page with a reference ID, and keep the details in your logs, where the reference ID lets you find them.

The same applies to response headers that announce exact server and framework versions.

Google treats 5xx responses as a temporary server problem and slows crawling. Indexed pages survive short outages. Pages that keep returning 500 are eventually dropped. A 500 on one template, such as every product page, can remove an entire section of a site from search while the homepage looks fine.

What a scan can and cannot tell you

WebAuditOS reports crawled pages that return 5xx as critical findings, checks whether error pages expose stack traces, and checks whether the Server header leaks software versions.

It sees only the requests a crawler makes: plain page loads. A 500 that happens on form submission, on a logged-in page or on one specific input will not appear in a public scan. Those need error tracking inside the application.

A clean scan means the public pages loaded at scan time. It says nothing about errors behind a login or on POST requests.

Short answers

Why does my app work locally but return 500 in production? Most often a missing environment variable or a database migration that ran locally but not in production.

Is a 500 a security problem? Not by itself. A 500 page that shows a stack trace is.

500 or 502? 500 comes from your app. 502 comes from a proxy that could not get an answer from your app.

Should I return 500 for bad user input? No. Bad input is a 4xx, usually 400 or 422.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.

HTTP errors

What does 502 Bad Gateway mean, and how do you fix it?

A 502 means a proxy or load balancer got no valid answer from your app. The usual causes on modern hosting, and how to find which layer failed.

HTTP errors

What does 404 Not Found mean, and how do you fix it?

A 404 means the server has nothing at that address. Why it happens, when it is the correct answer, and how to stop broken links costing you visitors.