Un error 503 Service Unavailable significa que el servidor web recibió la petición pero no puede procesarla en este momento. El servidor es accesible, así que el DNS y la red funcionan, pero la aplicación que hay detrás está sobrecargada, en mantenimiento o no consigue llegar a un servicio del que depende. Un 503 debería ser temporal. Si dura más de unos minutos, hay algo que arreglar: normalmente demasiado tráfico, pocos workers, un proceso de aplicación parado o un backend caído.
Esta guía explica qué provoca un 503, cómo encontrar la causa en tu propio servidor, cómo solucionar cada una y cómo asegurarte de enterarte del próximo antes que tus clientes.
Qué te dice realmente un 503
Los códigos de estado HTTP del rango 5xx indican que ha fallado el servidor, no el visitante. Dentro de esa familia, el 503 tiene un significado concreto: el servicio no está disponible por ahora y el cliente puede volver a intentarlo más tarde. Compáralo con sus vecinos:
500 Internal Server Error: la aplicación falló al procesar la petición.
502 Bad Gateway: un proxy o un balanceador de carga recibió una respuesta no válida del servidor que tiene detrás.
503 Service Unavailable: el servidor, o algo que tiene delante, se niega a procesar la petición porque está sobrecargado, en mantenimiento o no tiene nada sano a lo que enviarla.
504 Gateway Timeout: un proxy esperó al servidor que tiene detrás y se rindió.
La diferencia importa porque te indica dónde mirar. Un 503 rara vez es un bug en una página. Casi siempre tiene que ver con la capacidad o la disponibilidad de todo un servicio. Para ver todos los códigos y cuáles debería tratar un monitor como caída, consulta nuestra chuleta de códigos de estado HTTP para monitorización.
Causas habituales de un 503
Picos de tráfico y sobrecarga
Todo servidor puede atender un número limitado de peticiones a la vez. Un email de campaña, una mención en redes sociales o un bot rastreando miles de páginas pueden llevarlo por encima de ese límite. Cuando la cola se llena, el servidor web o la aplicación empieza a rechazar las peticiones nuevas con un 503. A menudo el sitio vuelve a funcionar unos minutos después y falla otra vez en el siguiente pico.
Mantenimiento programado
Muchos sistemas devuelven un 503 a propósito durante el mantenimiento. WordPress lo hace mientras instala actualizaciones: crea un archivo .maintenance y sirve una breve página de «No disponible por mantenimiento programado» con estado 503. Si una actualización se interrumpe, ese archivo puede quedarse y el sitio sigue devolviendo 503 hasta que alguien lo borra.
Proceso de aplicación o grupo de aplicaciones detenido
En servidores Windows con IIS, un grupo de aplicaciones detenido o caído produce el clásico «HTTP Error 503. The service is unavailable.». El grupo puede detenerse por caídas repetidas, una contraseña de identidad incorrecta o un cambio de configuración. En Linux, el equivalente es un proceso de Node, Python o Java que ha terminado y deja al proxy inverso sin nada a lo que reenviar.
PHP-FPM sin workers
Los sitios PHP detrás de nginx o Apache suelen usar PHP-FPM con un número fijo de procesos worker, definido por pm.max_children. Cuando todos los workers están ocupados, por ejemplo porque cada petición espera a una consulta lenta a la base de datos o a una API externa, las peticiones nuevas se ponen en cola. Según la configuración, el visitante recibe un 503, un 502 o un 504. El log de PHP-FPM te dice si está pasando:
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Límites de peticiones
Los límites de peticiones protegen al servidor de abusos, pero si son demasiado estrictos también devuelven errores a usuarios reales. nginx devuelve 503 por defecto cuando una petición supera una zona limit_req. Los firewalls de aplicaciones web y algunas plataformas de hosting hacen lo mismo. Si una oficina, un cliente de API o un servicio de monitorización comparte dirección IP con muchos usuarios, pueden alcanzar el límite entre todos.
Upstream o backend caído
Los balanceadores de carga y los proxies inversos devuelven 503 cuando no tienen ningún servidor sano al que enviar el tráfico. Si los health checks marcan todos los backends como no sanos, tras un despliegue fallido o porque la base de datos está caída y el endpoint de health check lo informa, el proxy responde 503 a todas las peticiones.
Problemas de la CDN y del origen
Si tu sitio está detrás de una CDN, el 503 puede venir de la CDN y no de tu servidor. La CDN puede devolverlo cuando tu origen está sobrecargado o inaccesible, o cuando la propia CDN tiene problemas en una región. Las cabeceras de la respuesta suelen decirte quién respondió: busca la cabecera server o el ID de petición propios de la CDN, y compara con una petición enviada directamente al origen.
Cómo encontrar la causa
Empieza por la propia respuesta. Solicita la URL que falla y mira las cabeceras:
curl -sS -o /dev/null -D – https://northwind.shop/checkout
La cabecera Server y las cabeceras propias de la CDN muestran qué capa respondió. Una cabecera Retry-After apunta a un mantenimiento deliberado. Después, avanza hacia dentro:
Comprueba si pasa en todas partes. ¿Falla también la página de inicio o solo una ruta? Una sola ruta apunta a una ruta de la aplicación o a un pool de workers; si falla todo, apunta al servidor o al proxy.
Lee el log de errores del servidor web. nginx y Apache registran con marca de tiempo los fallos del upstream, los rechazos por límite de peticiones y los errores de conexión.
Lee el log de la aplicación o de PHP-FPM. Busca avisos de max_children, caídas, procesos eliminados por falta de memoria y trazas de peticiones lentas.
Revisa los recursos del servidor. CPU, carga, memoria y swap en el momento del error. Un servidor que tira de swap responde despacio, y las respuestas lentas llenan los pools de workers.
Revisa las dependencias. ¿Responde la base de datos? ¿Funciona la caché? ¿Responde despacio una API externa a la que llamas de forma síncrona?
Revisa los cambios recientes. Un despliegue, la actualización de un plugin, un cambio de configuración o un nuevo límite de peticiones en torno al momento en que empezaron los errores es la causa más probable.
Cómo solucionar un 503
La solución depende de la causa. Estas son las habituales, en el orden en que la mayoría de los equipos se las encuentran.
Modo de mantenimiento atascado: elimina el archivo .maintenance de la raíz de WordPress o desactiva el indicador de mantenimiento de tu framework, y luego termina o repite la actualización.
Sobrecarga por tráfico real: cachea todo lo que puedas en el edge y en la aplicación, para que la mayoría de las peticiones nunca lleguen a PHP ni a la base de datos. Después añade capacidad: más workers si la memoria lo permite, un servidor más grande o más servidores detrás del balanceador de carga.
Sobrecarga por bots: identifica los user agents y los rangos de IP en tu log de accesos y limítalos o bloquéalos en la CDN o en el firewall, antes de que lleguen a la aplicación.
Workers de PHP-FPM: sube pm.max_children solo hasta donde lo permita la memoria. Calcula la memoria media de un worker y divide entre ella la memoria que puedes dedicarle. Si los workers están ocupados por consultas lentas, corrige primero las consultas o solo moverás el cuello de botella.
Grupo de aplicaciones o proceso detenido: reinícialo y luego averigua por qué se detuvo. Busca caídas en el visor de eventos o en el journal del sistema, y configura un gestor de procesos que reinicie el servicio automáticamente.
Límites de peticiones demasiado estrictos: sube el límite o el tamaño de ráfaga, excluye direcciones IP conocidas como las de tu oficina o tu servicio de monitorización, y devuelve 429 en lugar de 503 a los clientes limitados para que la causa sea evidente en los logs.
Backends no sanos: comprueba qué solicita el health check del balanceador de carga y por qué falla. Revierte primero un despliegue fallido e investiga después.
Este es un cambio típico del pool de PHP-FPM para un servidor con margen para más workers. Los números son un ejemplo, no una recomendación para tu servidor:
; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
Lo útil es el slow log: muestra qué scripts retienen más tiempo a los workers, y ahí es donde hay que mirar a continuación.
Usa Retry-After durante el mantenimiento programado
Cuando desconectes un sitio a propósito, devuelve un 503 con una cabecera Retry-After. Indica a los navegadores, a los clientes de API y a los rastreadores de los buscadores que la caída es temporal y cuándo volver. El valor es un número de segundos o una fecha HTTP:
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
En nginx, un interruptor de mantenimiento sencillo puede tener este aspecto:
if (-f /var/www/maintenance.flag) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 1800 always;
root /var/www/maintenance;
rewrite ^ /index.html break;
}
Dos reglas hacen que el mantenimiento programado no duela. Devuelve 503, nunca 200 con una página de «volvemos pronto», porque un 200 les dice a los rastreadores y a los monitores que la página de mantenimiento es tu contenido real. Y que sea breve: un 503 durante una hora está bien; un 503 durante días puede hacer que tus páginas desaparezcan de los resultados de búsqueda.
Avisa también a tus clientes con antelación. Una nota en tu página de estado responde a «¿solo me pasa a mí?» antes de que nadie lo pregunte.
Cómo detecta la monitorización los errores 503
Un 503 suele ir y venir. El sitio falla dos minutos en el pico de una campaña, se recupera y vuelve a fallar una hora después. Nadie del equipo lo ve, porque cuando alguien abre el sitio ya funciona. Pero los clientes sí lo vieron.
Un monitor HTTP solicita tus páginas de forma programada y registra el código de estado y el tiempo de respuesta de cada comprobación. Un 503 es una comprobación fallida. Una buena monitorización hace entonces tres cosas:
Confirma el fallo. Una segunda comprobación descarta un fallo puntual, y una comprobación desde otra ubicación descarta además un problema en una ruta de red concreta. Uptimecheck comprueba desde Estocolmo, Londres y Nueva York, y confirma cada fallo desde una segunda ubicación antes de abrir una incidencia.
Avisa a las personas adecuadas. La alerta incluye el código de estado, la URL y cuándo empezó, para que quien la atienda sepa que es un 503 y no un error de DNS. En Uptimecheck, la incidencia incluye también la respuesta fallida y una captura de pantalla, para que veas la página de error que vieron tus visitantes, o un traceroute cuando el servidor no respondió en absoluto. Consulta alertas y notificaciones para ver los canales.
Registra el patrón. El historial de incidencias muestra si los 503 se concentran en picos de tráfico, despliegues o tareas nocturnas, lo que te indica qué solución probar primero.
Monitoriza algo más que la página de inicio. A menudo está en caché y sigue funcionando mientras fallan el checkout, el inicio de sesión o la API. Añade monitores de uptime para las páginas que generan ingresos y vigila la tendencia del tiempo de respuesta: una página que se ralentiza cada día a la misma hora suele ser un 503 a punto de ocurrir. Nuestra guía sobre cuál es un buen tiempo de respuesta web explica en qué fijarte.
Las métricas del servidor cierran el círculo. Cuando llega una alerta de 503, la primera pregunta es si el servidor se quedó sin CPU, memoria o disco. Con la monitorización de servidores junto a tus comprobaciones de uptime, ves la causa y el síntoma lado a lado.
Checklist del error 503
Mira las cabeceras de la respuesta para ver qué capa devolvió el 503.
Revisa los logs del servidor web, de la aplicación y de PHP-FPM en la misma marca de tiempo.
Comprueba la CPU, la memoria, el swap y el disco del servidor.
Busca despliegues, actualizaciones y cambios de configuración justo antes de que empezaran los errores.
Corrige la causa: caché, más workers, un proceso reiniciado, un límite de peticiones más holgado o un backend sano.
Usa 503 con Retry-After para el mantenimiento programado, nunca 200.
Monitoriza las páginas clave cada minuto y confirma cada fallo con una segunda comprobación antes de alertar.
Resumen
Un 503 significa que el servidor está ahí pero no puede atenderte ahora mismo. Es un problema de capacidad o de disponibilidad, no una página rota, y los logs de la misma marca de tiempo suelen señalar directamente la causa. Corrige la causa en lugar del síntoma, usa Retry-After cuando la caída esté programada y deja que la monitorización te avise de los 503 breves que de otro modo nunca verías.
Uptimecheck monitoriza sitios web, APIs y servidores en una sola cuenta y te avisa cuando una página empieza a devolver 503. Empieza tu prueba gratuita de 14 días, sin tarjeta de crédito.