Skip to main content

How to fix a 500 Internal Server Error (step by step)

A 500 error means your server tried to handle the request and failed. The page gives you nothing useful on purpose — the real reason is in the logs. Here is the order that finds it fastest.

1. Confirm the scope

  • One page or the whole site? One page → likely a script or plugin error.

  • Whole site → server misconfiguration, resource exhaustion, or a bad deploy.

  • Is it 500, 502 or 504? They point at different layers (see our status code reference).

2. Read the error log

This is the step people skip. On most stacks the application log or the web server error log names the exact file and line.

text
# Apache
tail -50 /var/log/apache2/error.log

# nginx + PHP-FPM
tail -50 /var/log/nginx/error.log
journalctl -u php-fpm -n 50

3. The usual suspects

  • A plugin or dependency was just updated and is now incompatible.

  • A file permission or ownership changed so the app cannot read or write.

  • PHP memory limit or max execution time was hit.

  • A syntax error in a config file or .htaccess rule.

  • Disk is full, so the app cannot write sessions or logs.

4. Change one thing at a time

Disable the suspected plugin, fix the permission, or raise the limit — one change, then retest. Changing several things at once leaves you not knowing what fixed it.

5. Confirm, then write it down

Reload the page and verify the status is 200, not just that it looks right. Note what you changed so the next person (or the next you) starts here instead of at step one.

If 500s keep coming back after a rollout, that is a signal your deploy process is missing a staging check — worth fixing properly rather than chasing it each time.

← Back to all posts