Cómo investigar un error HTTP 503

Un 503 es un tipo de fallo distinto de un tiempo de espera agotado o una conexión rechazada. El servidor está ahí y respondió. Lo que dijo es que no puede atender la solicitud en este momento. El estándar HTTP describe el 503 como una condición temporal, normalmente de sobrecarga o de mantenimiento programado, y permite que el servidor indique cuándo volver a intentarlo.

Ese «temporal» es una promesa que hace el servidor, no una garantía. Esta guía te ayuda a averiguar qué tipo de 503 tienes y qué mirar primero.

Qué te dice la respuesta

Algo produjo la respuesta 503. Puede haber sido la aplicación, el servidor web, un balanceador de carga, un proxy o una red de distribución de contenido (CDN). Eso ya acota las cosas: la ruta de red y el DNS funcionan, porque la respuesta te llegó.

Merece la pena leer dos pistas antes de entrar en ningún sitio:

• La propia página. Un mensaje simple del servidor web, una página de mantenimiento con la marca y una página de error de una CDN apuntan cada una a una capa distinta.
• Las cabeceras. Busca una cabecera Retry-After, que indica cuántos segundos esperar o da una fecha. Un servidor que la envía suele estar diciéndote que el 503 es intencionado, por ejemplo durante un mantenimiento. Las cabeceras que nombran un proxy o una CDN muestran qué capa respondió.

Las tres causas comunes

Algunos servicios también responden 503 a propósito cuando un cliente envía demasiadas solicitudes, en lugar del más habitual 429. Si limitas la frecuencia de los visitantes, comprueba si el límite está atrapando tu propio tráfico.

Comprueba primero desde fuera

Antes de cambiar nada, mira lo que ve un visitante. Desde cualquier máquina:

curl -sS -o /dev/null -D - https://example.com/

Esto muestra la línea de estado y las cabeceras. Para ver cuánto tardó la solicitud y qué estado devolvió en una sola línea:

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/

Ejecútalo varias veces. Si devuelve 503 siempre, la condición es constante. Si alterna entre 200 y 503, probablemente uno de varios servidores detrás de un balanceador de carga no está sano, o los trabajadores se agotan de forma intermitente. Pide también a alguien en otra red que lo pruebe, para descartar una respuesta que dependa de dónde estés.

Trabaja de delante hacia atrás

Sigue la solicitud en el orden en que viaja:

1. CDN o proxy delante. ¿Es quien responde? Revisa su página de estado y su propio registro de errores. Una CDN que no puede llegar a tu servidor suele mostrar su propia página de error.
2. Balanceador de carga. ¿Lista todos los backends como sanos? Un backend que no supera su comprobación de estado se retira, y si no queda ninguno, el balanceador devuelve 503.
3. Servidor web y trabajadores de la aplicación. ¿Hay trabajadores libres? Un grupo lleno deja las solicitudes nuevas esperando, y algunas configuraciones responden 503 cuando la cola está llena. Busca líneas del registro que hablen de haber alcanzado un límite.
4. La aplicación y sus dependencias. Una base de datos llena o inalcanzable puede hacer que la aplicación rechace trabajo. También puede hacerlo un servicio posterior del que dependa la página.
5. Cambios recientes. Un despliegue, un cambio de configuración, una actualización de un plugin o un pico de tráfico poco antes del primer 503 es la explicación más común. Empieza tu cronología ahí.

Lee el patrón

El momento dice tanto como la respuesta:

• Una ráfaga de 503 durante un despliegue suele ser el propio reinicio. Se arregla cambiando la forma de desplegar, no persiguiendo el error.
• Un 503 a la misma hora todos los días apunta a una tarea programada, una copia de seguridad o un pico de tráfico que agota los recursos.
• Un 503 que sigue a unos tiempos de respuesta crecientes apunta a sobrecarga. El tiempo de respuesta suele subir durante minutos antes del primer 503. Consulta tiempo de respuesta.
• Un 503 solo para un visitante puede ser un límite de frecuencia, una dirección bloqueada o una regla de seguridad, no una caída.

Qué puede decirte un monitor

Un monitor que solicita tu dirección desde fuera no puede ver dentro del servidor, pero te da la cronología que necesitas.

UptimeWire cuenta como fallo cualquier respuesta final fuera del rango de 200 a 399, así que un 503 es un fallo. Una comprobación fallida se repite, y se abre un incidente tras tres comprobaciones fallidas seguidas, separadas unos 20 segundos. Se registra el motivo, por ejemplo «HTTP 503», con cuándo empezó y cuánto duró. Consulta incidentes de monitorización.

Esto ayuda en la práctica: puedes ver si el 503 fue una ráfaga corta o una caída larga, y si llegó siguiendo un patrón de horarios. No te dice la causa. UptimeWire no mira dentro de tu aplicación ni mide tu servidor.

Para trabajos planificados, el mantenimiento planificado de UptimeWire retiene las alertas de incidentes mientras dura el trabajo. Si un 503 corto en cada despliegue sigue generando alertas, consulta por qué los monitores de disponibilidad envían falsas alarmas.

Lista de comprobación

• ¿El 503 es constante o intermitente? Prueba varias veces.
• ¿Quién respondió: la aplicación, el servidor web, el proxy, el balanceador de carga o la CDN?
• ¿Hay una cabecera Retry-After y dice cuándo volver a intentarlo?
• ¿Hubo un despliegue, un cambio o un pico de tráfico justo antes?
• ¿Subió el tiempo de respuesta antes del primer 503?
• ¿Están sanos todos los backends y hay trabajadores libres?
• ¿El fallo sigue un calendario?

Cuando un 503 es la respuesta correcta

Un 503 durante un mantenimiento real es el comportamiento correcto. Les dice a los visitantes y a los buscadores que vuelvan más tarde, algo que no hace una página con un 200 que diga «cerrado por mantenimiento». Si planificas una interrupción, responde 503 a propósito y, cuando puedas, incluye Retry-After. Lo que importa es que el 503 termine cuando termine el trabajo.