HTTP 500 Internal Server Error: Where to Find the Cause in Your Logs

A 500 says something broke on the server and the server cannot be more specific. The response itself carries almost no information, which is why every fix starts with the log. This page is a map of where each stack writes the real error. For the general walkthrough of fixes, start with Fix 500 Internal Server Error; for the formal definition see the HTTP 500 reference.

If you are only a visitor, there is little you can do: reload once, try again later, and report it. The rest of this page is for people who run the server.

Step 1: confirm and note the time

Send one request and write down the exact time and path.

curl -sI https://example.com/failing-page | head -n 5
date -u

Check from outside with the HTTP Status Checker to confirm it is not just your network. Tools like the Outage Root Cause Finder can narrow whether the fault is DNS, TLS, the edge or the origin. Then use the timestamp to match lines in the logs below.

Step 2: find the layer that answered

The Server header, error page style and extra headers tell you whether a CDN, proxy or your origin returned the 500. Look with the HTTP Header Checker. A 500 from a CDN with Cloudflare branding may be an origin error passed through, or a Cloudflare-specific 5xx; see Cloudflare errors 520-526.

Step 3: read the log for your stack

Paths vary by distribution and setup, so confirm yours.

Web servers

• nginx: /var/log/nginx/error.log. Search around the time with sudo grep -n "$(date +%Y/%m/%d)" /var/log/nginx/error.log | tail. A 500 from nginx itself is often a rewrite loop (rewrite or internal redirection cycle). Most application 500s are generated upstream and nginx only passes them on, so continue to the app log.
• Apache: /var/log/apache2/error.log on Debian and Ubuntu, /var/log/httpd/error_log on RHEL-family systems. A .htaccess syntax error shows as Invalid command or not allowed here. Test with sudo apachectl configtest.
• LiteSpeed, shared hosting: use the error log icon in cPanel or the hosting panel.

PHP and WordPress

• PHP-FPM: pool logs sit near /var/log/php8.x-fpm.log, with application errors going to the file set by error_log in php.ini. Fatal errors, memory exhaustion (PHP allowed memory size exhausted) and syntax mistakes (PHP parse error) appear here.
• WordPress: add to wp-config.php, then read wp-content/debug.log:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Turn it off afterward. Plugin and theme conflicts are the usual cause; see WordPress plugin conflict troubleshooting and the white screen of death.

• Laravel: storage/logs/laravel.log (permission problems on storage/ and bootstrap/cache are classic). Set APP_DEBUG=false in production.

Node.js, Python, Ruby, Java

• Node.js: stdout and stderr go wherever your process manager sends them. With systemd, run journalctl -u myapp --since "10 minutes ago". With PM2, pm2 logs. Look for unhandled rejections and thrown exceptions.
• Python (Gunicorn, uWSGI, Django, Flask): journalctl -u gunicorn or the log file in your unit. Django writes tracebacks to the configured LOGGING handlers when DEBUG is off.
• Rails: log/production.log, with the request ID tying the 500 to a stack trace.
• Java (Tomcat, Spring Boot): logs/catalina.out or the application log, with Caused by: lines at the bottom of a stack trace being the real error.
• Docker/Kubernetes: docker logs --since 10m <container> or kubectl logs <pod> --previous if the pod restarted. See Docker website down checklist.

Step 4: match the error to a cause

Once you find the line, the cause tends to be one of these:

1. Code exception: fix the bug or roll back the last deploy.
2. Resource limits: memory, disk full, or open file limits. Check df -h and free -m.
3. Database failure: see MySQL too many connections and MySQL server has gone away.
4. Permissions or missing files: wrong owner on cache and upload directories.
5. Bad config after a change: revert it and retest.

Step 5: make it findable next time

Log request IDs, return them in a response header, and send errors to a central place. The Site Health Report and Website Health Check show what a visitor sees, and an Uptime Monitor alerts you at the first failure. After an incident, write it up with the incident postmortem template.

Next steps

• Follow the full 500 fix guide.
• Compare with 502 Bad Gateway and 503 Service Unavailable.
• Read the HTTP 500 reference.
• Add monitoring with the Uptime Monitor.

FAQ

Why is the 500 page so unhelpful?

Servers hide details on purpose, because stack traces can expose secrets. The details are in your logs.

The log is empty. What now?

Check you are reading the right file, that logging is enabled for the application and that the disk is not full. A 500 from a proxy or CDN will not appear in your app log at all.

Can a 500 be caused by the visitor?

Occasionally, if odd input triggers a bug. It is still a server bug; good code returns 4xx for bad input.

Does a 500 hurt SEO?

Short episodes are tolerated. Long or repeated 500s lead crawlers to slow down and may drop pages from the index.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.