Causas comunes del tiempo de inactividad de un sitio web

Cuando un sitio web se cae, el primer instinto es adivinar la causa. Reiniciar el servidor. Deshacer la versión publicada. Llamar al proveedor de alojamiento. A veces funciona. Lo más habitual es que se pierdan los primeros veinte minutos.

Es mejor empezar diciendo exactamente lo que estás viendo. El síntoma reduce la causa a una o dos capas, y cada capa tiene su propia primera comprobación. Esta guía se construye sobre esa idea. Para la definición de tiempo de inactividad y sus efectos, consulta tiempo de inactividad del sitio web.

¿Está caído para todo el mundo?

Antes de cambiar nada, averigua a quién afecta.

• Abre el sitio desde un teléfono con datos móviles, no desde la red de tu oficina.
• Mira qué registró tu monitorización: cuándo ocurrió el primer fallo y cuál fue el motivo.
• Pide a un compañero que esté en otro lugar que lo pruebe.
• Comprueba si falla solo una página, un país o un tipo de dispositivo.

Si solo tú ves el problema, la causa probablemente es local: tu red, una respuesta de DNS en caché, una VPN o una extensión del navegador. Si lo ve todo el mundo, sigue leyendo.

Del síntoma a la primera comprobación

La RFC 9110 define los tres códigos de pasarela. Un 502 significa que una pasarela o proxy recibió una respuesta no válida del servidor que tiene detrás. Un 503 significa que el servidor no puede atender la solicitud ahora, normalmente por sobrecarga o mantenimiento, y puede incluir una cabecera Retry-After. Un 504 significa que la pasarela no obtuvo respuesta a tiempo. En los tres casos, la puerta de entrada está abierta y el problema está más adentro.

Comandos para echar un primer vistazo

Desde cualquier máquina con un terminal:

curl -I https://example.com/

Esto muestra la línea de estado y las cabeceras sin el cuerpo. Para obtener más detalle, incluidos la consulta DNS, la conexión y el paso del certificado, añade -v:

curl -v https://example.com/ -o /dev/null

El punto donde se detiene la salida te dice dónde falla. Si se detiene antes de «Connected», el problema es el nombre o la red. Si se detiene durante el paso del certificado, revisa el certificado. Si obtienes una línea de estado, el servidor respondió, y el estado te indica el siguiente paso.

Servidor y alojamiento

La máquina puede estar apagada, sin memoria, sin espacio en disco o sobrecargada. Un disco lleno es un fallo silencioso: las bases de datos dejan de escribir, los registros se llenan y la aplicación empieza a fallar de formas extrañas.

Consulta primero la página de estado del proveedor de alojamiento y después la propia máquina: procesos en ejecución, memoria, disco y carga. Un incidente del propio proveedor de nube puede parecerse mucho a un fallo tuyo, así que mira su página de estado antes de dedicar una hora a tu configuración.

Aplicación y despliegues

Una versión fallida es una de las causas más comunes de una caída que empieza en un minuto preciso. Si el fallo empezó justo después de un despliegue, deshaz primero el cambio e investiga después.

Las señales típicas son errores 500, una página en blanco o una aplicación que arranca y luego se cierra. El registro de la aplicación en el momento del primer fallo suele nombrar la excepción. Una dependencia nueva que no está instalada, un valor de entorno que falta y un cambio en la base de datos que el código no espera son causas frecuentes.

Proxies, balanceadores de carga y CDN

Muchos sitios están detrás de un proxy inverso, un balanceador de carga o una red de distribución de contenido. Cuando el proxy funciona y el servidor que tiene detrás no, los visitantes ven 502 o 504, a menudo en una página con la marca del proxy. Esa marca te indica que la capa frontal está viva y que debes mirar detrás de ella.

Revisa el registro del propio proxy para ver el error del servidor de origen. Un tiempo de espera del proxy más corto que la solicitud más lenta de la aplicación producirá errores 504 aunque la aplicación esté sana.

DNS y el dominio

Si el nombre deja de resolverse, el sitio es inalcanzable por muy sano que esté el servidor. Entre las causas están un registro eliminado, un servidor de nombres cambiado, una caída del proveedor y un dominio vencido.

Sigue Cómo solucionar errores de resolución DNS para encontrar la capa y comprueba el registro con Cómo comprobar cuándo vence un dominio.

Certificados

Un certificado caducado, o emitido para un nombre distinto, hace que los navegadores muestren una advertencia a pantalla completa. El servidor está en marcha, pero los visitantes no pasarán. Comprueba las fechas y los nombres del certificado. La causa y la prevención se explican en Cómo evitar que caduque un certificado SSL.

Sobrecarga

Un pico de tráfico, una tarea pesada en segundo plano o un buscador que rastrea demasiado rápido pueden agotar toda la capacidad. Las señales son, primero, páginas lentas, luego errores 503 o 504 y después tiempos de espera agotados. A menudo se recupera sin intervención y vuelve en el siguiente pico.

Mira el gráfico de carga durante los minutos previos al primer fallo. Si los tiempos de respuesta subieron de forma constante antes de la caída, es probable que se trate de sobrecarga.

Servicios de terceros

Una página puede cargar mientras falla una función: el pago, el inicio de sesión, la búsqueda o un mapa. El servicio que hay detrás está caído o va lento. Desde fuera, el sitio parece activo. Lee el error que la aplicación registra sobre la llamada que falla y consulta la página de estado del proveedor.

Qué puede decirte un monitor

Una comprobación desde el exterior, como la de UptimeWire, solicita la dirección y lee la respuesta. Si la comprobación falla, registra un motivo. Los motivos que distingue incluyen:

• no se pudo resolver el nombre de dominio,
• falló la conexión,
• no hubo respuesta en 15 segundos,
• el certificado TLS o la conexión no son válidos,
• el servidor respondió con un código de estado determinado,
• no se encontró en la página el texto esperado.

Ese motivo te lleva a la fila correcta de la tabla anterior antes de que abras un servidor. UptimeWire abre un incidente tras tres comprobaciones fallidas seguidas, separadas unos 20 segundos, y conserva el motivo con él. Consulta Cómo monitorizar la disponibilidad de un sitio web para la configuración.

Una comprobación que lee un código de estado no puede ver un inicio de sesión que rechaza todas las contraseñas. Consulta también por qué los monitores envían falsas alarmas para el problema contrario.

Después de la recuperación

Cuando el sitio vuelva a responder, anota:

• la hora del primer fallo y la hora de la recuperación,
• el síntoma y la causa,
• qué lo arregló,
• qué te habría hecho darte cuenta antes.

Esas cuatro líneas bastan para convertir una caída en algo que la siguiente persona pueda aprovechar.

Lista de comprobación

• Di el síntoma en una frase.
• Comprueba si afecta a todo el mundo.
• Lee el motivo del fallo registrado.
• Ejecuta curl -v y mira dónde se detiene.
• Revisa el último despliegue o cambio.
• Revisa el DNS, el dominio y el certificado, que fallan sin que cambies nada por tu parte.
• Anota la causa y la solución.