Solucionar problemas

Error 503 Service Unavailable

Revisado el 5 min de lectura errores http recursos

El error 503 Service Unavailable indica que el servicio no puede atender la petición en ese momento. Puede ser temporal, pero hay que identificar su origen antes de cambiar la configuración.

El código es genérico. Antes de cambiar recursos o PHP, guarda la URL, hora, cuerpo y cabeceras de una única respuesta y consulta los registros web, PHP y de la aplicación del mismo instante. El contenido de la página puede revelar si el 503 lo generó la aplicación, un modo de mantenimiento, un proxy o el servidor.

Consumo de recursos excedido

Cada servicio de hosting dispone de unos recursos asignados; CPU, memoria RAM y número de procesos simultáneos.

Estos límites ayudan a aislar el consumo entre cuentas del servidor. No equivalen a disponer de una máquina física dedicada ni descartan una incidencia compartida.

No todos los límites producen un 503. En CloudLinux, CPU e I/O suelen ralentizar la cuenta; el límite de procesos de entrada suele producir 508; memoria o número de procesos pueden terminar en 500, 503 o procesos finalizados. Comprueba los contadores de fallos LVE del mismo intervalo antes de atribuir el código a recursos.

cPanel permite depurar los usos de recursos y obtener snapshots de aquellos procesos que generan estos consumos, de forma que se puede obtener una información clave para localizar la causa.

Los snapshots muestran procesos y peticiones activas, pero no garantizan la causa. En WordPress o Drupal pueden señalar index.php por ser el front controller; correlaciona entonces la URL con el registro y el perfilado de la aplicación.

Entre las causas que conviene contrastar con los registros están:

  • Plugins o temas con bajo rendimiento o fallos: aísla el componente solo después de recopilar evidencia, mediante una prueba reversible y preferiblemente en staging o con mantenimiento y copia disponible. No desactives indiscriminadamente todos los componentes en producción.
  • Falta de optimización, una web puede funcionar de forma normal y rápida con pocas visitas y en cambio crear un "cuello de botella" cuando empezamos a ver más accesos simultáneos, esto se debe a que cada proceso utiliza gran cantidad de recursos, la solución pasa por analizar y optimizar nuestras aplicaciones para reducir el consumo de recursos lo que a su vez mejorará la velocidad de carga.
  • Si los fallos comienzan tras una actualización de un plugin o app, verifica los requisitos de la nueva versión para adaptar versiones de PHP, módulos y configuración, si son correctos, consulta al desarrollador para comprobar si existe un fallo en esa actualización. Si necesitas volver atrás, comprueba la fecha y disponibilidad de una copia de seguridad.

En última instancia, si nuestra app está optimizada en todo lo posible, podría ser simplemente que por crecimiento del proyecto necesite más recursos, puedes cambiar a un plan superior para obtener una mayor asignación de CPU y memoria o contactarnos para analizar tus necesidades.

Aplicación, mantenimiento o backend

Comprueba si la aplicación activó un modo de mantenimiento o genera su propio 503. Si el registro identifica PHP-FPM, LSAPI o un backend no disponible, revisa ese servicio. Cambia versión o módulos de PHP únicamente cuando el error exacto o los requisitos de la aplicación demuestren incompatibilidad; puedes adaptar la configuración PHP después de confirmarla.

Problema interno en el sistema

Si los registros y métricas no exponen el origen, contacta con soporte con URL, hora, respuesta exacta y pasos para reproducirla.

Verificar la recuperación

Repite una petición equivalente y comprueba el código, el contenido y las métricas. En una tienda, que la portada vuelva a cargar no confirma que funcionen carrito o pago. Si valoras restaurar, conserva antes los pedidos, mensajes o cambios posteriores a la copia y planifica cómo reconciliarlos.

Si el 503 procede de un mantenimiento previsto, comprueba su duración y la respuesta que reciben usuarios y buscadores. Evita dejar indefinidamente la web en ese estado. Un plan superior tiene sentido cuando las métricas confirman falta de capacidad; no corrige una excepción de código ni una redirección incorrecta.

También te puede ayudar

¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.