El tiempo de inactividad es el tiempo en el que un sitio web no puede cumplir su función. Los visitantes pueden ver una página de error, una página que nunca termina de cargar o un aviso del navegador. Lo que importa es el resultado: no pueden usar el sitio.
El tiempo de inactividad es la contrapartida de la disponibilidad (uptime). Un sitio con una disponibilidad del 99,9 % en un mes de 30 días acumula unos 43 minutos de inactividad.
Inactividad planificada y no planificada
La inactividad planificada se decide con antelación. Los motivos típicos son una migración de base de datos, una actualización del servidor o un despliegue importante que no puede convivir con la versión anterior. La buena práctica es programarla en horas de poco tráfico, avisar antes a los usuarios y mostrar una página de mantenimiento clara. Un servidor que se apaga a propósito por mantenimiento suele responder con 503 Service Unavailable, que indica una situación temporal y puede incluir una cabecera Retry-After que dice a los clientes cuándo volver.
La inactividad no planificada es todo lo demás: fallos que nadie programó. Es la que hace daño, porque llega sin avisar y el reloj corre hasta que alguien se da cuenta y lo arregla.
Los contratos y los informes suelen tratar ambas de forma distinta. Muchos acuerdos de nivel de servicio excluyen del cálculo el mantenimiento anunciado. Que eso se aplique a un sitio concreto depende por completo de la redacción que se haya pactado.
Causas habituales
| Causa | Qué ocurre | Qué suele ver un visitante |
|---|---|---|
| Fallo del servidor | La máquina o el servidor virtual se bloquea, se queda sin memoria o sin disco, o se sobrecarga | Conexión rechazada, tiempo de espera agotado o un error 5xx |
| Problema de red | Un enlace, una regla de cortafuegos o un fallo del proveedor corta el tráfico entre el visitante y el servidor | Tiempo de espera agotado, «no se puede acceder a este sitio» |
| Problema de DNS | El nombre de dominio no se resuelve porque un registro es incorrecto o se ha eliminado, o porque el dominio ha vencido | «No se encuentra el servidor» |
| Problema de certificado | El certificado TLS ha caducado o no coincide con el dominio | Una advertencia de seguridad del navegador a pantalla completa |
| Fallo de la aplicación | Un error de programación, un despliegue fallido o una dependencia rota bloquea la aplicación | Un error 500 o una página en blanco |
| Sobrecarga | Un pico de tráfico o una tarea pesada consume toda la capacidad disponible | Páginas muy lentas, errores 503 o 504 |
| Dependencia de terceros | Un servicio de pagos, de inicio de sesión o de base de datos del que depende el sitio deja de responder | Una página que carga, pero en la que una función falla |
Muchas caídas combinan varias causas. Un servidor sobrecargado falla y el reinicio se retrasa por un certificado caducado en el servidor de respaldo. Mirar el primer fallo suele importar más que el último síntoma.
Cómo se manifiesta el tiempo de inactividad en HTTP
Cuando un visitante carga una página, el servidor devuelve un código de estado HTTP. Los códigos del rango 5xx, como 500, 502, 503 y 504, indican que el servidor ha fallado. Si no se puede alcanzar el servidor en absoluto, no hay código de estado, solo un tiempo de espera agotado o un error de conexión. El significado de cada clase se explica en códigos de estado HTTP.
Lo que una comprobación de petición web no puede ver
Este es el límite más importante que hay que entender. Una comprobación de monitorización que solicita una página y lee la respuesta solo puede informar de lo que dice el servidor. No puede saber si el sitio funciona.
Un servidor puede devolver 200 OK mientras:
- el carrito de la compra falla cuando alguien pulsa «añadir»,
- el formulario de inicio de sesión rechaza todas las contraseñas,
- la página carga pero está vacía porque ha fallado una llamada al backend,
- se muestra un mensaje de error dentro de una página que por lo demás es normal.
Desde el punto de vista del monitor, el sitio está activo. Desde el punto de vista de un cliente, está caído. Detectar estos fallos requiere comprobaciones que sigan recorridos reales de usuario, alertas a nivel de aplicación, o ambas cosas. Una comprobación simple de una dirección es una primera línea de defensa fiable para las caídas en las que el servidor no responde o responde con un error, y nada más que eso.
Consecuencias
Los efectos del tiempo de inactividad dependen de para qué sirva el sitio:
- Ingresos perdidos cuando los clientes no pueden pedir ni pagar.
- Confianza perdida cuando los usuarios se encuentran un error donde esperaban un servicio.
- Carga de soporte cuando la gente pregunta si el problema está de su lado.
- Penalizaciones contractuales cuando un acuerdo define objetivos de disponibilidad y créditos.
Detectar y recuperarse
El tiempo de inactividad se acorta con tres cosas: darse cuenta rápido, entender la causa y tener una vía de vuelta.
- Detectar. Un monitor comprueba el sitio a intervalos y lanza una alerta tras varios fallos seguidos, para que una sola petición perdida no despierte a nadie. UptimeWire, por ejemplo, repite dos veces una comprobación fallida, con unos 20 segundos de diferencia, antes de abrir un incidente.
- Diagnosticar. La comprobación fallida registra un motivo, como un tiempo de espera agotado, un error de conexión o un código de estado. Eso acota la búsqueda: un error de DNS y un error 500 apuntan a lugares completamente distintos.
- Recuperar. Las recuperaciones habituales son reiniciar un servicio, deshacer un lanzamiento, restaurar un certificado o corregir un registro DNS. Cuando el sitio vuelve a responder correctamente, las comprobaciones se superan y el incidente se cierra.
- Aprender. Una nota breve sobre la causa y la solución, guardada junto al incidente, ayuda la próxima vez.
El tiempo que pasa desde el inicio de la caída hasta que alguien lo sabe también forma parte del tiempo de inactividad. Por eso importa el intervalo de comprobación: un sitio comprobado cada minuto puede detectarse antes que uno comprobado cada diez minutos.