Algo salió mal en el servidor.
Cuándo usarlo
Excepciones no controladas. Registra los detalles, no se los muestres al cliente.
Causas habituales y soluciones
Un 500 significa una excepción no controlada o un error de configuración en el servidor. Empieza por los logs del momento de la solicitud: stack traces de la aplicación, logs de errores de PHP o Python, journalctl, docker logs o CloudWatch. Causas habituales: un valor null o undefined, una consulta a la base de datos que falla o una migración sin aplicar, una variable de entorno que falta en producción, un error de sintaxis en .htaccess o permisos incorrectos en un script.
Haz que los 500 se puedan depurar: devuelve un ID de solicitud en una cabecera y en el cuerpo, regístralo junto con el stack trace y envía los errores a un tracker como Sentry. Nunca muestres stack traces a los clientes en producción. No uses 500 para errores del cliente; los fallos de validación corresponden a los 4xx, y así las alertas sobre 5xx siguen siendo significativas. Reintentar con backoff ayuda con los fallos transitorios, pero un bug determinista falla siempre.
Error del servidor (5xx)
Los códigos 5xx son errores del servidor: puede que la solicitud sea correcta, pero el servidor o algo detrás de él ha fallado. Conviene configurar alertas para ellos.
Cómo se ve
HTTP/1.1 500 Internal Server ErrorCómo enviarlo
| Node.js / Express | res.status(500).end() |
|---|---|
| Python / Flask | return '', 500 |
| nginx | return 500; |
Cómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/