Qué significa un 503 Service Unavailable y de quién es la culpa

Un 503 Service Unavailable es el único error de servidor que normalmente es a propósito. Algo decidió que esta petición no se iba a atender ahora mismo, y lo dijo, en lugar de intentarlo y fallar.

Eso lo convierte en el raro de su familia. Un 500 es código que se rompió mientras se ejecutaba. Un 502 es un proxy que recibe una respuesta inservible de aquello que tiene detrás. Un 504 es eso mismo que no responde nunca a tiempo. Los tres son fallos. Un 503 es una decisión.

Las cuatro cosas que toman esa decisión

Desde un navegador se ven idénticas y significan cosas completamente distintas para quien lleva el sitio.

Modo mantenimiento. Alguien puso el sitio deliberadamente detrás de una página de espera mientras corre una migración o aterriza un despliegue. Aquí el 503 funciona exactamente como se diseñó, y es el único caso en el que la respuesta correcta es volver más tarde.

La aplicación no acepta conexiones. Todos los workers están ocupados, el pool de conexiones está lleno, la cola que tiene delante está en su límite. El servidor de delante sigue en pie y sigue respondiendo, así que responde con lo único honesto que tiene: ahora no.

Un limitador de tasa. Usted, o la red en la que está, ha enviado más peticiones de las que permite un umbral. Algunos servicios usan un 429 para esto, que es más específico y más útil; muchos usan 503, y una CDN puesta delante de una aplicación a menudo convierte uno en el otro.

No hay nada corriendo. Un autoescalador que no ha alcanzado un pico de tráfico, un despliegue en el que la versión nueva no ha pasado su health check, un contenedor que murió y no ha sido reemplazado. El balanceador de carga tiene destinos sanos a los que mandar tráfico, no encuentra ninguno, y devuelve un 503 porque no hay adónde mandarlo.

Solo el primero de esos está planificado. Los otros tres son el sistema diciendo que está al límite o que ha perdido algo, en la forma cortés reservada para una condición temporal.

La cabecera que casi nadie lee

Un 503 es el código de estado que lleva una respuesta pegada. La respuesta puede llevar Retry-After, que dice o cuántos segundos esperar o la fecha y hora exactas a las que volver:

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/html

Eso es el sitio diciéndole que serán dos minutos. Las páginas de mantenimiento bien configuradas la ponen, las CDN la dejan pasar, y enviarla no cuesta nada.

De ahí se siguen dos cosas, y apuntan en direcciones opuestas. Si está escribiendo un cliente, lea la cabecera en lugar de inventarse su propio backoff: a un servicio que le ha dicho 120 segundos y recibe un reintento cada dos se le está pidiendo que atienda justo las peticiones que acaba de decir que no podía atender. Y si lleva el sitio, póngala. Un 503 con Retry-After es un buscador que retiene la página en lugar de tratarla como desaparecida, y un cliente que espera como es debido en lugar de uno que suma a la carga que causó el problema.

Si es usted el visitante

Un 503 normalmente significa esperar, y, cosa rara en un error, la espera a menudo funciona. Recargue al cabo de uno o dos minutos. Si es un despliegue o un pico, se aclara solo, y no hay nada en su navegador que lo toque en ningún caso.

Lo único que merece la pena comprobar es si le pasa solo a usted. Un 503 que le sale a todo el mundo es la capacidad del sitio o su ventana de mantenimiento. Un 503 que le sale a usted y no a un compañero en otra red es más probablemente un limitador de tasa que le ha tomado ojeriza a su dirección, y un móvil con datos responde a esa pregunta en unos diez segundos. En esa distinción consiste entero distinguir su bug de la caída de ellos.

Si el sitio es suyo

La respuesta no le dice casi nada, pero a diferencia de un 500, la causa suele estar delante de la aplicación y no dentro de ella.

Empiece por qué capa lo emitió. Un 503 de nginx, de un balanceador de carga o de una CDN se ve igual desde el navegador y viene de tres sitios distintos con tres logs distintos. A menudo el cuerpo lo delata, porque cada uno de ellos trae su propia página por defecto, y las cabeceras de respuesta suelen nombrar a lo que las produjo. Si su aplicación no llegó a ejecutarse, su log estará en silencio, y ese silencio es una prueba y no un callejón sin salida.

Luego la pregunta obvia, que es fácil saltarse cuando un sitio está caído: ¿sigue puesto el modo mantenimiento? Una página de espera que debía durar diez minutos y ha sobrevivido al despliegue que la levantó es un 503 lo bastante común como para mirarlo primero, y descartarlo lleva segundos.

Si es capacidad, la solución no está en la página de error. Mire la saturación de los workers, los límites del pool y la profundidad de la cola a lo largo de la ventana, en lugar de mirar las peticiones que se llevaron el 503, porque las que se llevaron el 503 son las que llegaron después de que empezara el problema. Si son los health checks, la pregunta es si el check tiene razón en que la aplicación está enferma o si está fallando por un motivo propio, y esas dos cosas piden respuestas opuestas.

Por qué un 503 merece que se informe bien

La mayoría de los 503 se aclaran. Eso es justo lo que los hace escurridizos: para cuando alguien investiga, el sitio ha vuelto y no hay nada que mirar. Lo que queda es el recuerdo que alguien tiene de una página de error y una sospecha sobre más o menos cuándo.

Los problemas de capacidad y los despliegues malos no se repiten a demanda. Ocurren en el momento en que el tráfico cruzó una línea, y la prueba de ellos es una ventana en una gráfica que nadie sabe que hay que ir a mirar a menos que alguien apuntara cuándo pasó.

Para un 503 la parte útil es la marca de tiempo y las cabeceras de respuesta: qué capa contestó, qué Retry-After afirmó, y el minuto exacto. Con eso basta para encontrar la ventana correcta en un panel, que es donde vive de verdad la respuesta.

En un párrafo

Un 503 Service Unavailable significa que algo eligió no atender la petición en lugar de intentarlo y fallar, y eso es lo que lo separa de un 500, un 502 y un 504. Cuatro cosas toman esa decisión: el modo mantenimiento, una aplicación que se ha quedado sin capacidad, un limitador de tasa, y un balanceador de carga sin nada sano a lo que mandar tráfico. Solo la primera está planificada. Si está de visita, espere un minuto y luego compruebe si alguien más lo ve. Si el sitio es suyo, averigüe qué capa contestó antes que nada, asegúrese de que el modo mantenimiento no sigue simplemente puesto, y ponga Retry-After para que los clientes que esperan esperen bien en lugar de sumar a la carga.