The symptom

The browser shows a generic error page. The response is a 500. There's no detail, no line number, nothing to go on.

The first move, always

Stop looking at the browser. A 500 means the server threw an exception, and the exception is in the server's logs with a full stack trace and a line number.

Find your logs:

  • A host with a dashboard — there's a logs tab. Look at the timestamp of your request.
  • Your own server — the application log, and the web server's error log. Both matter, and they're different files.
  • Serverless — the function's log stream in the provider's console.

If you genuinely can't reach logs, fixing that is your actual task. You will need them every time from now on.

Then read the trace properly

The useful line is usually not the top one. Read down to the first file that's yours — that's where the problem is. Everything above it is framework code doing what it was asked.

read-the-trace.txt
Here is the full stack trace: <paste all of it>
Here is the code at the line it points to: <paste>

Tell me:
1. What this error actually means, in plain English.
2. What specifically in my code triggered it.
3. What value was probably unexpected — null, empty, wrong type?
4. The fix.
5. What I should have logged to spot this faster.

The usual culprits

Something null or undefined that you assumed existed. A database call failing or timing out. A missing environment variable. A file path that doesn't exist on the server. A third-party call that errored and wasn't handled.

Prevent the next one

Turn on error reporting that captures exceptions with stack traces and sends them somewhere you'll see. Free tiers are generous and it takes fifteen minutes. Then you find out about 500s before your users tell you.

Never enable detailed error pages in production to debug this. Stack traces shown to visitors leak file paths, library versions and sometimes credentials.