Error 503 Service Unavailable: qué es, causas y cómo solucionarlo

El error 503 Service Unavailable es un código de estado HTTP que indica que el servidor no puede atender solicitudes en este momento, pero se espera que la situación sea temporal. Es un error de la familia 5xx, lo que significa que la solicitud del cliente es correcta y el problema está en el servidor. A diferencia del error 500 (fallo inesperado e indefinido) o del error 502 (respuesta inválida del servidor de destino), el 503 comunica explícitamente que la indisponibilidad es temporal y que el servidor podría volver a estar operativo pronto. Las causas más frecuentes son sobrecarga de tráfico, falta de workers disponibles en PHP-FPM, modo de mantenimiento activo en WordPress y base de datos no disponible.

Qué significa exactamente el error 503

El código 503 está definido en el RFC 9110 con esta descripción: "The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay." (El servidor no puede atender la solicitud actualmente debido a una sobrecarga temporal o a un mantenimiento programado, que probablemente se resolverá después de un tiempo).

Hay dos conceptos clave en esta definición que distinguen al 503 del resto de errores 5xx:

1. Temporalidad: el 503 implica que la situación es temporal y que el servidor volverá a estar disponible. No es un fallo permanente ni un error de código.
2. Causa comunicada: el servidor puede y debe comunicar cuándo espera volver a estar disponible mediante la cabecera Retry-After, algo que no existe en otros errores 5xx.

Esta comunicación de temporalidad tiene implicaciones importantes para el SEO: Google trata el 503 de forma especial si viene acompañado de la cabecera Retry-After, respetando el tiempo de espera indicado y no desindexando el contenido de forma precipitada.

Error 503 vs 500, 502 y 504: diferencias clave

La distinción práctica más importante entre 502 y 503: el 502 indica que el servidor de destino responde pero con algo inválido (el servicio está roto o caído definitivamente); el 503 indica que el servidor existe y está operativo en condiciones normales, pero ahora mismo no puede atender más solicitudes porque está saturado o en mantenimiento.

La cabecera Retry-After: el mecanismo más importante del 503

La cabecera Retry-After es el elemento que convierte al 503 en el error HTTP más "educado" de todos. Permite al servidor comunicar a clientes y robots cuándo se espera que el servicio vuelva a estar disponible, evitando que reintentos masivos inmediatos empeoren la sobrecarga.

Tiene dos formatos válidos según el RFC 9110:

# Formato 1: número de segundos hasta que se puede reintentar
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html

# Formato 2: fecha y hora exacta en formato HTTP (RFC 7231)
HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 03 Jun 2026 14:00:00 GMT
Content-Type: text/html

Comportamiento de los agentes más importantes ante la cabecera Retry-After:

Recomendación para SEO: siempre incluye la cabecera Retry-After cuando devuelvas un 503, especialmente durante mantenimientos programados. Google la respeta explícitamente y es la forma más efectiva de proteger el posicionamiento durante una ventana de mantenimiento.

Causas más comunes del error 503

1. Servidor sobrecargado por pico de tráfico

Cuando el tráfico supera la capacidad de procesamiento del servidor, las nuevas solicitudes no pueden ser atendidas y el servidor devuelve 503. Esto ocurre con mayor frecuencia en:

• Campañas de marketing o lanzamientos que generan picos de tráfico repentinos.
• Aparición en prensa o en redes sociales (el llamado "efecto Slashdot" o "abrazo de la muerte de Reddit").
• Ataques DDoS que saturan el servidor con solicitudes falsas.
• Picos de tráfico estacional (Black Friday, rebajas, eventos).
• Rastreos agresivos de bots que consumen todos los recursos del servidor.

El primer indicador de esta causa es que el error aparece de forma repentina, afecta a todos los usuarios simultáneamente y coincide con un aumento anormal de tráfico en los logs o en las métricas del servidor.

# Verificar la carga del servidor en tiempo real:
top
htop

# Ver el número de conexiones activas al servidor web:
ss -tn | grep :443 | wc -l
ss -tn | grep :80 | wc -l

# Ver las IPs con más conexiones (útil para detectar DDoS o bots agresivos):
ss -tn | grep :443 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Ver el tráfico por minuto en los logs de Nginx:
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-2 | sort | uniq -c | tail -20

2. PHP-FPM sin workers disponibles

En stacks LEMP (Nginx + PHP-FPM), PHP-FPM gestiona un pool de procesos worker que atienden las solicitudes PHP. Cuando todos los workers están ocupados y la cola de espera también está llena, PHP-FPM rechaza las nuevas conexiones. Dependiendo de cómo esté configurado Nginx, esto puede resultar en un error 502 o 503.

El mensaje característico en los logs de PHP-FPM:

WARNING: [pool www] seems busy (you may need to increase pm.max_children),
spawning 32 children, there are 0 idle, and 24 waiting for a process slot

WARNING: [pool www] server reached pm.max_children setting (50),
consider raising it

Diagnóstico y solución:

# Ver el número actual de procesos PHP-FPM y su estado:
ps aux | grep php-fpm | wc -l
ps aux | grep php-fpm | grep -c "idle\|active"

# Ver el estado del pool en tiempo real (si está configurado el status):
curl http://localhost/fpm-status

# Calcular el pm.max_children correcto:
# pm.max_children = RAM disponible para PHP / RAM media por proceso PHP-FPM
# Ejemplo: 4GB disponibles / 50MB por proceso = 80 workers máximo

# Ajustar la configuración del pool en /etc/php/8.2/fpm/pool.d/www.conf:
pm = dynamic
pm.max_children = 80
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 50
pm.max_requests = 500

# Aplicar los cambios:
sudo systemctl reload php8.2-fpm

# Verificar que se aplicaron correctamente:
sudo systemctl status php8.2-fpm

3. WordPress en modo de mantenimiento

WordPress activa automáticamente el modo de mantenimiento durante las actualizaciones del núcleo, plugins y temas. Lo hace creando un archivo .maintenance en la raíz del sitio y mostrando una página de mantenimiento con código 503. En condiciones normales, este archivo se elimina automáticamente cuando la actualización termina.

El problema ocurre cuando la actualización falla a mitad del proceso o cuando el archivo .maintenance no se elimina correctamente, dejando el sitio atrapado en modo de mantenimiento indefinidamente. El sitio muestra el mensaje "No disponible para mantenimiento programado. Vuelve en un minuto" indefinidamente.

# Verificar si existe el archivo .maintenance:
ls -la /var/www/html/tudominio/.maintenance

# Ver el contenido del archivo (contiene el timestamp de cuando empezó la actualización):
cat /var/www/html/tudominio/.maintenance

# Eliminar el archivo para salir del modo de mantenimiento:
rm /var/www/html/tudominio/.maintenance

# Si el problema ocurre frecuentemente, revisar los permisos del directorio:
ls -la /var/www/html/tudominio/

# Verificar que WordPress puede escribir y eliminar archivos en la raíz:
sudo -u www-data touch /var/www/html/tudominio/test_write.tmp
sudo -u www-data rm /var/www/html/tudominio/test_write.tmp

Importante: si el sitio entró en modo de mantenimiento porque una actualización falló a mitad del proceso, eliminar el archivo .maintenance hará que el sitio vuelva a estar accesible, pero puede que WordPress o los plugins queden en un estado inconsistente. Verifica el funcionamiento completo del sitio después de eliminar el archivo y, si hay problemas, restaura desde la última copia de seguridad antes de la actualización fallida.

4. Base de datos no disponible o saturada

WordPress y la mayoría de los CMS y aplicaciones web dependen de la base de datos para generar cada página. Si MySQL o MariaDB está caído, sobrecargado, o ha alcanzado el límite de conexiones simultáneas, las aplicaciones no pueden obtener los datos necesarios y devuelven un 503 (o un error específico de conexión a la base de datos, dependiendo de la configuración).

# Verificar el estado de MySQL:
sudo systemctl status mysql
sudo systemctl status mariadb

# Ver si MySQL está respondiendo:
mysqladmin -u root -p status

# Ver el número de conexiones activas y el límite configurado:
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"

# Ver procesos activos en MySQL (útil para detectar consultas bloqueadas o lentas):
mysql -u root -p -e "SHOW PROCESSLIST;"

# Ver consultas lentas:
sudo tail -50 /var/log/mysql/mysql-slow.log

# Aumentar el límite de conexiones si es necesario (en /etc/mysql/mysql.conf.d/mysqld.cnf):
max_connections = 300

# Reiniciar MySQL si está caído:
sudo systemctl restart mysql

5. Límite de conexiones del servidor web alcanzado

Apache y Nginx tienen configurados límites máximos de conexiones simultáneas. Cuando se alcanza ese límite, el servidor no puede aceptar nuevas conexiones y devuelve 503. Esto puede ocurrir incluso si el servidor tiene recursos de CPU y RAM disponibles, porque el límite de conexiones es una restricción de configuración independiente.

# En Apache — ver y ajustar el MaxRequestWorkers:
grep -r "MaxRequestWorkers\|MaxClients" /etc/apache2/

# En /etc/apache2/mods-available/mpm_prefork.conf:
<IfModule mpm_prefork_module>
    StartServers            5
    MinSpareServers         5
    MaxSpareServers         10
    MaxRequestWorkers       150    # Aumentar si el 503 es por límite de conexiones
    MaxConnectionsPerChild  0
</IfModule>

# En Nginx — ver y ajustar el worker_connections:
grep -r "worker_connections\|worker_processes" /etc/nginx/nginx.conf

# En /etc/nginx/nginx.conf:
worker_processes auto;       # Usa todos los cores de CPU disponibles
events {
    worker_connections 1024; # Conexiones por worker. Total = workers * connections
    multi_accept on;         # Acepta múltiples conexiones por evento
}

# Verificar el límite actual del sistema operativo:
ulimit -n  # Límite de archivos abiertos (cada conexión usa un descriptor de archivo)

# Aumentar el límite del sistema si es necesario:
sudo sysctl -w fs.file-max=100000

6. Mantenimiento programado en el proveedor de hosting o CDN

A veces el 503 no viene de tu servidor sino de la infraestructura de tu proveedor de hosting o de tu CDN. Cloudflare, por ejemplo, puede devolver 503 durante mantenimientos de su propia red o cuando detecta tráfico que considera abusivo hacia tu sitio. Los proveedores de hosting también pueden generar 503 durante migraciones de servidores, actualizaciones de infraestructura o intervenciones de emergencia.

Para distinguir si el 503 viene de tu servidor o de la infraestructura del proveedor:

# Comprueba si el servidor responde directamente (saltándose el CDN):
# 1. Obtén la IP real de tu servidor (en Plesk o el panel de hosting)
# 2. Modifica tu archivo hosts local para apuntar el dominio a esa IP:
#    195.234.56.78  tudominio.com
# 3. Intenta acceder a https://tudominio.com desde el navegador

# Si funciona directamente por IP pero no a través del dominio/CDN:
# el problema está en el CDN o en el DNS, no en tu servidor

# Verificar el estado de Cloudflare:
# https://www.cloudflarestatus.com/

# Verificar el estado de tu proveedor de hosting:
# sys4net: https://status.sys4net.com/

Cómo solucionar el error 503: proceso de diagnóstico

Paso 1: Determina si el 503 es generalizado o específico

¿El 503 afecta a todos los usuarios o solo a algunos? ¿Afecta a todo el sitio o solo a ciertas páginas? ¿Empezó de repente o después de una actualización o cambio de configuración? Las respuestas orientan hacia la causa:

Paso 2: Revisa los logs del servidor

# Nginx — buscar errores de upstream y 503:
sudo grep " 503 " /var/log/nginx/access.log | tail -30
sudo tail -100 /var/log/nginx/error.log | grep -i "503\|unavailable\|upstream"

# Apache — buscar 503:
sudo grep " 503 " /var/log/apache2/access.log | tail -30
sudo tail -100 /var/log/apache2/error.log

# PHP-FPM — buscar mensajes de workers:
sudo tail -100 /var/log/php8.2-fpm.log | grep -i "busy\|max_children\|timeout"

# MySQL — buscar errores de conexión:
sudo tail -100 /var/log/mysql/error.log

Paso 3: Verifica el estado de todos los servicios

# Verificar todos los servicios relevantes de una vez:
sudo systemctl status nginx
sudo systemctl status php8.2-fpm
sudo systemctl status mysql
sudo systemctl status apache2  # Si usas Apache

# Ver la carga del sistema:
uptime
free -h          # RAM disponible
df -h            # Espacio en disco
vmstat 1 5       # Estadísticas del sistema en tiempo real

Paso 4: Gestiona la sobrecarga si el 503 es por tráfico

# Activar rate limiting en Nginx para limitar las solicitudes por IP:
# En /etc/nginx/nginx.conf, dentro del bloque http:
limit_req_zone $binary_remote_addr zone=general:10m rate=30r/m;

# En el bloque server o location:
limit_req zone=general burst=20 nodelay;
limit_req_status 429;  # Devuelve 429 (Too Many Requests) en lugar de 503

# Bloquear una IP específica que está generando carga excesiva:
# En /etc/nginx/nginx.conf, bloque http:
deny 195.234.1.100;

# Para un ataque DDoS más amplio, considera activar el modo "Under Attack" en Cloudflare:
# Cloudflare Dashboard > [tu dominio] > Security > Settings > Security Level > I'm Under Attack

Cómo configurar correctamente una página de mantenimiento con 503

Cuando necesitas hacer un mantenimiento programado en tu sitio, la forma correcta de comunicarlo es mostrar una página de mantenimiento con código 503 y la cabecera Retry-After. Esto protege el SEO y comunica a los visitantes cuándo volverá a estar disponible el sitio.

En Apache con .htaccess

# En el .htaccess de la raíz del sitio:
RewriteEngine On

# Permite el acceso desde tu IP para poder trabajar durante el mantenimiento:
RewriteCond %{REMOTE_ADDR} !^195\.234\.56\.78$

# Redirige todo el tráfico a la página de mantenimiento:
RewriteCond %{REQUEST_URI} !/mantenimiento.html$
RewriteCond %{REQUEST_URI} !/mantenimiento.css$
RewriteRule ^(.*)$ /mantenimiento.html [R=503,L]

# Configurar el código 503 y la cabecera Retry-After:
ErrorDocument 503 /mantenimiento.html
Header always set Retry-After "7200"  # El sitio estará disponible en 2 horas

En Nginx

# En el bloque server del sitio:
server {
    listen 443 ssl;
    server_name tudominio.com;

    # Permite acceso desde tu IP de trabajo:
    set $maintenance 1;
    if ($remote_addr = "195.234.56.78") {
        set $maintenance 0;
    }

    # Redirige todo el tráfico a la página de mantenimiento:
    if ($maintenance = 1) {
        return 503;
    }

    error_page 503 @mantenimiento;

    location @mantenimiento {
        root /var/www/html/tudominio;
        rewrite ^(.*)$ /mantenimiento.html break;
        add_header Retry-After 7200;  # Disponible en 2 horas
    }
}

En WordPress con un plugin de mantenimiento

Si usas WordPress, los plugins de mantenimiento como WP Maintenance Mode, Coming Soon Page o SeedProd permiten activar y configurar la página de mantenimiento desde el panel, sin acceso SSH. Lo importante es verificar que el plugin devuelve un código 503 real (no un 200 con contenido de mantenimiento, que es incorrecto para el SEO) y que incluye la cabecera Retry-After.

# Verificar qué código HTTP devuelve tu página de mantenimiento:
curl -o /dev/null -s -w "HTTP Code: %{http_code}\n" https://tudominio.com

# Verificar las cabeceras completas, incluyendo Retry-After:
curl -I https://tudominio.com

# El resultado correcto debe incluir:
# HTTP/2 503
# retry-after: 7200

Error 503 en WordPress: resumen de casos y soluciones

Impacto del error 503 en el SEO y cómo minimizarlo

El error 503 es el único error HTTP de la familia 5xx que tiene un mecanismo específico para comunicar temporalidad (Retry-After) y que Google trata de forma diferenciada. Aun así, si no se gestiona correctamente, puede tener un impacto significativo en el posicionamiento:

Impacto según la duración del 503

Cómo proteger el SEO durante un mantenimiento programado

1. Programa el mantenimiento en horas de bajo tráfico: las madrugadas de días laborables son las ventanas con menos tráfico real y menor frecuencia de rastreo de Googlebot.
2. Usa siempre el código 503, no el 200: una página de mantenimiento que devuelve 200 (que es lo que hacen algunos plugins mal configurados) puede hacer que Google indexe la página de mantenimiento en lugar del contenido real.
3. Incluye siempre la cabecera Retry-After: con el tiempo estimado real del mantenimiento. Google la respeta y no desindexo si el plazo es razonable.
4. Verifica que el código 503 llega a Google: usa curl -I https://tudominio.com para confirmar que el servidor devuelve 503 y no 200 ni otro código.
5. Solicita nueva indexación tras el mantenimiento: en Google Search Console, usa la herramienta URL Inspection para solicitar una nueva indexación de las páginas principales una vez el sitio esté operativo.

Preguntas frecuentes sobre el error 503

¿El error 503 es temporal o puede volverse permanente?

Por definición, el 503 es temporal. Sin embargo, si no se resuelve la causa subyacente (sobrecarga, MySQL caído, archivo .maintenance olvidado), el error puede persistir indefinidamente aunque su naturaleza sea técnicamente temporal. La diferencia con el 500 o el 502 es que el 503 indica que el servidor está operativo en condiciones normales y que la indisponibilidad es circunstancial, no estructural. Dicho esto, un 503 persistente tiene el mismo impacto práctico en el SEO que cualquier otro error 5xx que dure más de 24-72 horas.

¿Cómo sé si el 503 lo genera mi servidor o Cloudflare?

Si la página de error tiene el diseño visual de Cloudflare (con su logo, el texto "Error 503 Service Unavailable" y un Ray ID al pie), el 503 lo está generando Cloudflare, normalmente porque no puede contactar con tu servidor de origen o porque tu servidor de origen devuelve un error. Si la página de error es sencilla o tiene el estilo de Nginx o Apache, el 503 viene de tu propio servidor. Puedes confirmarlo haciendo curl -I https://tudominio.com y mirando las cabeceras de respuesta: si incluyen cabeceras de Cloudflare (CF-Ray, CF-Cache-Status), el error pasa por Cloudflare.

¿Por qué WordPress entra en modo de mantenimiento solo?

WordPress activa el modo de mantenimiento automáticamente al inicio de cualquier actualización del núcleo, plugins o temas, creando el archivo .maintenance en la raíz del sitio. En condiciones normales, este archivo se elimina automáticamente cuando la actualización termina correctamente. Si la actualización falla a mitad del proceso (por un timeout, un error de permisos o un problema de red), el archivo puede quedar sin eliminar. También pueden activarlo los plugins de mantenimiento o las actualizaciones automáticas nocturnas que configuraste en WordPress.

¿Cuándo debo usar 503 en lugar de 200 para una página de mantenimiento?

Siempre que el sitio esté en mantenimiento y no puedas servir el contenido normal, debes usar 503. Usar 200 para una página de mantenimiento es un error grave desde el punto de vista del SEO: Google indexará la página de mantenimiento como si fuera el contenido real del sitio, reemplazando en su índice las páginas originales con el mensaje de mantenimiento. El 503 indica a Google que el contenido existe pero no está disponible temporalmente, preservando el posicionamiento. El 200 le dice a Google que el contenido del sitio ahora es la página de mantenimiento.

¿El 503 afecta al posicionamiento aunque dure poco tiempo?

Un 503 de menos de una hora, especialmente si incluye la cabecera Retry-After con un valor razonable, tiene un impacto mínimo o nulo en el posicionamiento. Google está diseñado para tolerar interrupciones breves del servidor sin penalizar el ranking. El problema empieza cuando el 503 persiste más de 24 horas, momento en que Google puede empezar a reducir la frecuencia de rastreo y, si supera las 72 horas, a desindexar páginas. La clave es resolver el 503 lo antes posible y usar Retry-After para comunicar la temporalidad.

¿Qué diferencia hay entre un 503 y un "modo mantenimiento" en WordPress con código 200?

La diferencia es crítica para el SEO. Un 503 correcto indica a Googlebot que el contenido existe pero no está disponible temporalmente, lo que preserva el posicionamiento y la indexación. Un modo de mantenimiento con código 200 le dice a Googlebot que el contenido actual del sitio es la página de mantenimiento, y Google puede indexarla como si fuera el contenido real, sobreescribiendo en su índice las páginas originales. Verifica siempre con curl -I https://tudominio.com que tu página de mantenimiento devuelve 503 y no 200, independientemente del plugin o método que uses para mostrarla.