---
title: "500 Internal Server Error"
canonical: "https://lemwatch.com/http-status-codes/500"
category: "server-error"
last_verified: "2026-08-11"
source: "https://lemwatch.com"
---

# HTTP 500 Internal Server Error

**TL;DR** — A 500 means your server broke and doesn't know why. The fix is always the same shape: open the error log (server, application, and CDN), find the stack trace from the moment of failure, and work backwards. The most common real causes are bad recent deploys, database overloads, expired credentials, and out-of-memory crashes — in that order.

## What it means

HTTP 500 Internal Server Error is the universal "something broke on our end" response. It is deliberately vague because the server hit a condition the application code didn't know how to handle: an unhandled exception, a database connection that timed out, a misconfigured config file, an out-of-memory crash, a syntax error in a recent deploy. Unlike 4xx errors (which point the finger at the client), 500 is the server admitting fault. It is the single most common server-side error on the web and almost always means "check the application logs immediately."

## Common causes

- Uncaught exception in application code (PHP, Python, Node.js, Ruby, Java)
- Database connection failure or query timeout
- Misconfigured server file (.htaccess, nginx.conf, web.config) — common after a deploy
- Out-of-memory: process killed by the OOM killer or PHP memory_limit exceeded
- Broken or incompatible plugin/module after an update (WordPress, Drupal, Magento)
- File permission issues (web server cannot read/write required files)
- Expired API credentials or database password rotation breaking a backend call
- Disk full — server can't write logs, sessions, or temp files

## How to fix

- Open the application error log first — the stack trace from the moment of failure tells you almost everything
- Check the web server error log second (nginx /var/log/nginx/error.log, Apache /var/log/apache2/error.log) for config and permission issues
- Roll back the most recent deploy if the timing matches — bad code is the #1 cause
- Verify database connectivity with a direct connection: mysql -u user -p host, psql -h host -U user
- Check disk space (df -h) and memory (free -m / OOM killer in dmesg)
- For PHP/WordPress: bump memory_limit to 256M, disable plugins one by one to isolate the bad one
- For Node.js: check the process manager (PM2, systemd) for crash loops and review the unhandledRejection log
- If the 500 only fires under load, add caching (Redis, Varnish) or scale the bottleneck (DB connection pool, worker processes)

## SEO impact

Critical SEO impact when persistent. Googlebot retries 500 responses (a brief spike of 500s during a deploy is forgiven), but pages that consistently return 500 for hours or days are deindexed. Worse, a sitewide 500 outage during a Googlebot crawl can cause Google to throttle crawl rate for weeks afterward as a protective measure. Users bouncing immediately from a 500 page also send a strong negative engagement signal. Set up uptime monitoring with sub-5-minute detection so a 500 outage doesn't silently last overnight.

## Monitoring tip

LemWatch alerts within seconds when a monitored page starts returning 500. We track error frequency over time and surface patterns (always at 3am? during deploys? under load spikes?) so you can fix root causes instead of just restarting the server.

**Related:** [502](https://lemwatch.com/http-status-codes/502.md), [503](https://lemwatch.com/http-status-codes/503.md), [504](https://lemwatch.com/http-status-codes/504.md), [521](https://lemwatch.com/http-status-codes/521.md)

_Canonical HTML page: https://lemwatch.com/http-status-codes/500_