Un error 500 Internal Server Error significa que la aplicación del servidor se encontró con un problema que no supo gestionar mientras generaba la respuesta. A diferencia de la mayoría de los errores, no dice qué ha fallado. Es la forma que tiene el servidor de decir «algo se ha roto y no voy a contarle al visitante qué».
Pero el mensaje de error real existe: está en un log. Esta guía te muestra dónde encontrarlo, qué hay detrás de la mayoría de los errores 500 y cómo asegurarte de ser el primero en enterarte cuando aparezca uno.
Qué te dice un 500
Un 500 lo genera la propia aplicación o el servidor web que la ejecuta. Significa que la petición llegó a tu código y que el código falló: una excepción que nadie capturó, un error fatal, una configuración que el servidor no pudo leer. Eso lo distingue de los errores de gateway, en los que el problema está entre dos servidores:
500 Internal Server Error: la aplicación falló al procesar la petición.
502 Bad Gateway: un proxy recibió una respuesta no válida de la aplicación. Consulta nuestra guía del error 502.
503 Service Unavailable: el servicio está sobrecargado o en mantenimiento. Consulta nuestra guía del error 503.
504 Gateway Timeout: la aplicación tardó demasiado en responder. Consulta nuestra guía del error 504.
Un 500 en una sola página suele indicar un bug en el código de esa página. Un 500 en todas las páginas suele indicar que se ha roto algo compartido: la configuración, la conexión a la base de datos, un archivo que carga toda la aplicación.
Empieza por lo que ha cambiado
La mayoría de los errores 500 aparecen justo después de un cambio. Antes de leer un solo log, pregúntate qué ha pasado en la última hora:
Un despliegue o un merge a la rama principal
Una actualización de un plugin, un tema, un framework o del lenguaje
Un cambio en un archivo de configuración, en .htaccess o en las variables de entorno
Una contraseña o una clave de API renovada
Un servidor que se quedó sin disco o al que le cambiaron los permisos
Si el momento encaja, revertir el cambio suele ser la forma más rápida de recuperar el sitio. Busca la causa después, sin clientes mirando.
Encuentra el mensaje de error real
La página del 500 es genérica; el log es concreto. Dónde mirar depende de tu stack:
# nginx and Apache
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
# PHP-FPM
tail -n 50 /var/log/php8.3-fpm.log
# Applications run by systemd
journalctl -u myapp –since «15 min ago»
# Docker
docker logs –since 15m myapp
Busca la marca de tiempo de la petición que falla. La entrada que la acompaña suele indicar el archivo, la línea y el motivo: una función no definida, una clase que falta, una base de datos que rechazó la contraseña.
En WordPress, activa el log de depuración en wp-config.php. Escribe los errores en wp-content/debug.log sin mostrárselos a los visitantes:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
Desactívalo cuando termines, porque el log puede crecer mucho y contener datos sensibles.
Causas habituales y cómo solucionarlas
Un error en el código
Una excepción no capturada o un error fatal en el código que genera la página. El log muestra el archivo y la línea. Los desencadenantes típicos son una función que recibe datos que no esperaba, un valor que de repente llega vacío y código que funciona en el equipo del desarrollador pero necesita una extensión de PHP o una versión de una librería que el servidor no tiene. Corrige el código o vuelve a la última versión que funcionaba.
Una actualización de un plugin o tema
En WordPress y otros CMS, la actualización de un plugin o un tema es la causa más frecuente. El log indica la carpeta del plugin. Si no puedes entrar en el panel de administración, cambia el nombre de esa carpeta por SSH o SFTP para desactivarlo:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
El sitio vuelve a funcionar sin él. Después, actualízalo de nuevo, sustitúyelo o escribe a su desarrollador con el error del log.
Un archivo .htaccess roto
En Apache, una sola línea incorrecta en .htaccess tumba todo el sitio con un 500. El log de errores dice Invalid command o nombra la directiva que no entendió. Cambia el nombre del archivo para probar y luego restaura las líneas una a una. En WordPress, guardar los ajustes de enlaces permanentes genera uno nuevo.
PHP se queda sin memoria
Allowed memory size of 134217728 bytes exhausted significa que una petición necesitó más memoria de la que permite memory_limit. Subir el límite puede ayudar, pero una petición que necesita cientos de megabytes suele cargar demasiados datos de golpe. Averigua qué carga antes de darle más.
Permisos y propietario de los archivos
Tras un despliegue, una restauración o una copia manual, los archivos pueden acabar perteneciendo al usuario equivocado. Entonces el servidor web no puede leer el código ni escribir en sus carpetas de caché y de subidas, y el log dice Permission denied. Devuelve la propiedad al usuario con el que se ejecuta el servidor web o PHP. Los directorios suelen necesitar 755 y los archivos 644; nunca lo arregles con 777.
Un disco lleno
Cuando el disco está lleno, las aplicaciones no pueden escribir sesiones, cachés, subidas ni logs, y fallan de formas que acaban en un 500. Comprueba el espacio y los inodos:
df -h
df -i
Los logs antiguos, las copias de seguridad y las cachés son los culpables habituales. La monitorización de servidores con una alerta de disco al 80 o al 90 por ciento lo detecta días antes de que rompa el sitio.
Errores de conexión a la base de datos
Una contraseña cambiada, un servidor de base de datos caído o un límite de conexiones alcanzado. La aplicación no puede cargar nada y falla en todas las páginas. El log indica el error de la base de datos. Comprueba que la base de datos está en marcha, que las credenciales de la configuración están al día y cuántas conexiones hay abiertas frente al límite.
El 500 que devuelve 200
No todas las páginas rotas lo dicen. Algunas aplicaciones capturan el error y muestran una amable página de «Algo ha salido mal» con estado 200, y un CMS puede mostrar una lista de productos vacía sin quejarse. Para un monitor que solo mira el código de estado, todo parece correcto.
Comprueba también el contenido. Un monitor de uptime puede exigir que una página contenga una palabra que siempre está cuando funciona, como el nombre del producto o «Añadir al carrito», y tratar su ausencia como un fallo. Nuestra checklist de qué monitorizar indica qué páginas merecen ese tipo de comprobación.
Cómo detecta la monitorización los errores 500
Un 500 tras un despliegue puede pasar desapercibido durante horas si solo afecta a una página. El checkout se rompe, la página de inicio sigue funcionando y el equipo se entera por el email de un cliente o por una caída de las ventas.
Comprueba las páginas que generan ingresos. Añade monitores de uptime para el checkout, el inicio de sesión, el registro y la API, no solo para la página de inicio, con comprobaciones de contenido donde un 200 pueda ocultar un error.
Confirma antes de alertar. Uptimecheck comprueba hasta cada minuto desde Estocolmo, Londres y Nueva York, y confirma cada fallo desde una segunda ubicación, para que una sola petición fallida no despierte a nadie.
Mira qué se ha roto. La incidencia incluye la respuesta fallida, con el código de estado y la página de error, y una captura de pantalla de lo que vio el visitante.
Prueba flujos completos. Un inicio de sesión o un checkout que falla en el tercer paso devuelve 200 en el primero. Los flujos de varios pasos recorren todos los pasos y te dicen cuál ha fallado.
Checklist del error 500
Pregúntate qué ha cambiado en la última hora y revierte el cambio si el momento encaja.
Busca la marca de tiempo de la petición fallida en el log de errores.
Lee el error: archivo, línea y motivo.
Descarta las causas habituales: un plugin, .htaccess, la memoria, los permisos, el disco, la base de datos.
Corrige la causa y luego quita los ajustes de depuración que hayas activado.
Monitoriza las páginas clave cada minuto, con comprobaciones de contenido donde un 200 pueda ocultar un error.
Prueba los inicios de sesión y los checkouts como flujos, no como páginas sueltas.