HTTP 503 indica que el servicio no está disponible temporalmente. Puede generarlo WordPress, un mecanismo de mantenimiento, el proxy inverso, una capa de seguridad o el control de recursos del hosting. Cuando aparece y desaparece, suele coincidir con procesos saturados, tareas programadas o picos de tráfico.
No te conformes con que una recarga funcione. Registra cuándo, dónde y bajo qué carga aparece la respuesta.
Identifica el origen del 503
Revisa cabeceras, cuerpo e identificador de petición. Una página de mantenimiento de WordPress no es igual que un desafío de Cloudflare, un aviso de recursos de LiteSpeed o la respuesta de salud de un balanceador.
Registra:
URL y hora
firma del cuerpo y cabeceras
usuario anónimo frente a conectado
origen frente a CDN
cabecera Retry-After
métricas de recursos del alojamientoNo incluyas cookies, direcciones IP ni parámetros de clientes en informes compartidos.
Comprueba el estado de mantenimiento
Una actualización interrumpida del núcleo, plugin o tema puede dejar .maintenance en la raíz. Mira su fecha y comprueba si sigue activo algún proceso antes de retirarlo.
Elimina el archivo solo después de guardarlo y confirmar que no hay ningún despliegue en marcha. Después investiga por qué se detuvo la extracción: disco, permisos, timeout o paquete fallido.
Los plugins de mantenimiento pueden devolver 503 intencionadamente a visitantes anónimos mientras el administrador ve la web.
Relaciona tráfico y capacidad PHP
Revisa peticiones, procesos activos y máximos de PHP-FPM, cola, CPU y RAM. Si el 503 coincide con los picos, averigua qué rutas ocupan el pool.
Los bots, ataques al acceso y páginas dinámicas sin caché pueden agotar los workers. Limita únicamente los patrones abusivos sin bloquear visitantes normales ni callbacks programados.
Aumentar procesos sin calcular memoria puede provocar que el sistema los mate y empeorar la caída.
Revisa los límites del alojamiento
Un hosting compartido puede limitar procesos simultáneos, CPU, E/S o procesos de entrada y responder con 503 al superarlos. Los gráficos de recursos de cPanel suelen mostrar los fallos en la hora exacta.
Relaciona el incidente con esos eventos y localiza el proceso que consume. Las copias grandes, importaciones y generación de imágenes deben ejecutarse fuera de horas punta y en lotes acotados.
No cambies a un plan superior antes de demostrar si domina el código ineficiente o el tráfico abusivo.
Examina las tareas programadas
WP-Cron puede iniciar copias, escaneos, importaciones y limpiezas con la llegada de un visitante. Varias tareas vencidas pueden ejecutarse juntas después de un periodo tranquilo.
Consulta los registros de cron y Action Scheduler alrededor del 503. Pasa el trabajo pesado a un cron real del servidor y evita solapamientos con el bloqueo compatible de la herramienta.
No borres eventos desconocidos sin identificar su plugin y su finalidad.
Comprueba base de datos y dependencias externas
Los procesos PHP pueden quedar ocupados mientras esperan bloqueos MySQL, DNS, SMTP o APIs remotas. Examina consultas lentas y duración de peticiones.
En integraciones propias, establece tiempos máximos acotados y saca de la petición pública el trabajo remoto no esencial.
Un fallo de base de datos puede mostrar el mensaje propio de WordPress en vez de 503. Relaciona registros en lugar de deducir solo desde el navegador.
Mide peticiones lentas simultáneas: varias llamadas aceptables por separado pueden agotar todos los workers al coincidir.
Revisa health checks y balanceadores
En un alojamiento con varios nodos, uno defectuoso puede causar 503 intermitentes mientras los demás responden. Compara cabeceras, identificadores de nodo y eventos de salud.
La ruta del health check debe ser ligera, pero comprobar las dependencias necesarias para servir WordPress. Un archivo estático en caché puede informar que todo está bien aunque PHP esté caído.
Retira del reparto solo el nodo afectado mediante controles autorizados y compara la configuración del clúster.
Repara y demuestra estabilidad
Corrige el resto de mantenimiento, consumidor de recursos, capacidad PHP, solapamiento programado, espera de base de datos o nodo defectuoso que indiquen las pruebas. Conserva reversión y notas de seguimiento.
Ejecuta repetidamente peticiones anónimas y administrativas durante un periodo representativo, incluida la ventana de la tarea programada. El mantenimiento recurrente debería alertar por tasa de 503, colas PHP y límites del hosting: el uptime aislado puede pasar por alto cortes breves que interrumpen continuamente a usuarios reales.