¿Funciona el sitio? Monitorización uptime e incidentes
Con qué rapidez nota una empresa que su sitio está caído: monitorización uptime, cadena de alertas y una revisión posterior que de verdad se lee.
Equipo de rabbitclipPublicación: 5 min. de lectura
En breve
La monitorización uptime es una comprobación externa que se ejecuta según un calendario y registra si un sitio web o app responde de verdad. Una comprobación básica solo mira si la página de inicio carga; una configuración más fiable prueba una transacción real, pago, inicio de sesión, envío de un formulario, con la misma frecuencia. El objetivo es notar una caída antes que un cliente, y eso solo funciona si una alerta está definida de antemano: a quién llega, por qué canal, en cuánto tiempo.
Si la página de pago de un fabricante de ropa de trabajo empieza a dar errores un domingo por la mañana, puede pasar inadvertido durante horas si una queja de un cliente es la primera señal. Una comprobación que vigila el propio proceso de pago detecta el mismo fallo en minutos y avisa a la persona correcta; la diferencia está entre una pérdida de horas y una reacción de pocos minutos.
¿Qué mide realmente la monitorización uptime?
La monitorización uptime es el registro de si un servidor o una página, consultado desde un punto de control externo según un calendario, normalmente cada uno a cinco minutos, responde en absoluto. La respuesta debe existir y además llevar el contenido esperado, el código de estado correcto, un texto concreto en la página; que el servidor sea simplemente alcanzable no basta por sí solo, la página tiene que funcionar de verdad.
Este tipo de comprobación detecta bien un servidor que se ha caído por completo o ha dejado de responder, pero no siempre detecta una ralentización, un error parcial, o un problema que solo aparece en un navegador concreto. Por eso la monitorización uptime se suma al seguimiento de errores y a la monitorización de rendimiento, no los sustituye.
¿Qué comprobación detecta qué problema?
Distintos tipos de comprobación cubren distintos riesgos; elegir uno no hace innecesarios a los demás.
- comprobación ping/HTTP: si el servidor responde en absoluto, en segundos
- comprobación de contenido: si la página cargó correctamente, según un texto concreto o un código de estado
- comprobación sintética: si un proceso de varios pasos como el pago, el inicio de sesión o un envío de formulario funciona de principio a fin
- comprobación de certificado SSL: cuánto falta para que caduque el certificado
Cómo construir una cadena de alertas
Una alerta que no llega a nadie, o que llega a todos a la vez de modo que nadie se hace cargo, es donde la monitorización falla con más frecuencia en la práctica. Una escalada por etapas reduce ese riesgo.
- detección inicial: la comprobación automática confirma el fallo en 2-3 intentos consecutivos, para que un simple corte de red no se confunda con una caída
- 0-5 minutos: notificación inmediata a la persona de guardia, en la app o por correo
- 5-15 minutos: si no hay respuesta, se dispara un SMS o una llamada, y se avisa a una segunda persona
- pasados 15 minutos: interviene un responsable, se actualiza la página de estado
¿Qué ocurre durante una caída?
La primera tarea en cuanto se detecta una caída no es arreglarla, sino entender su alcance: está caído todo el sitio o solo una parte, cuántos usuarios se ven afectados, cuándo empezó. Actuar sin esa información arriesga a corregir lo que no toca mientras se pasa por alto la causa real.
Una página de estado pública rinde sus frutos en este momento; permite al soporte dirigir a cada cliente a una sola página actualizada en lugar de responder uno por uno. La página debe mantenerse al día hasta que termine la caída, y cerrarse una vez resuelta.
Por qué nunca hay que saltarse la revisión posterior al incidente
Una vez resuelta la caída, se escribe una revisión breve: qué pasó, cuándo se notó, cuánto tardó en arreglarse, qué va a cambiar para que no vuelva a pasar. El documento existe para evitar una repetición, no para señalar culpables.
Si el sistema de reservas de una cadena de spas se cae dos veces seguidas por la misma razón, el problema no es técnico sino de proceso; lo que la primera revisión pidió corregir nunca se aplicó de verdad. Una segunda caída por la misma causa merece tomarse más en serio que la primera, no menos.
Errores frecuentes
La monitorización uptime puede convertirse en una herramienta que se configura una vez y se olvida; eso ocurre casi tan a menudo como las caídas que se supone que debe detectar.
- monitorizar solo la página de inicio dejando el pago o el inicio de sesión sin vigilancia
- enviar las alertas a una sola persona, de modo que nadie nota su ausencia
- comprobar con muy poca frecuencia, por ejemplo cada treinta minutos, pasando por alto las caídas cortas
- pasar directamente a la siguiente crisis sin hacer una revisión posterior al incidente
La monitorización uptime no evita una caída; hace que se note antes que un cliente y que se gestione de forma ordenada. Una cadena de alertas bien construida y el hábito de una revisión posterior breve acortan la duración de la próxima. Una primera llamada con rabbitclip es un buen sitio para revisar juntos su configuración actual de monitorización.
Preguntas frecuentes
¿Se puede hacer monitorización uptime con herramientas gratuitas?
Sí, una comprobación básica de ping/HTTP la cubren muchos planes gratuitos. La monitorización sintética y las comprobaciones más frecuentes suelen estar en los planes de pago.
¿Con qué frecuencia deben ejecutarse las comprobaciones?
Entre uno y cinco minutos es habitual para páginas críticas. Comprobaciones más frecuentes detectan antes los problemas, pero también añaden carga al servidor.
¿Todo sitio necesita una página de estado?
Merece la pena para sitios con mucha interacción con clientes y para el comercio electrónico. Un sitio informativo de poco tráfico puede prescindir de ella.
¿La revisión posterior al incidente sirve para señalar culpables?
No. El objetivo es evitar una repetición; la revisión analiza el proceso y el sistema, no a una persona.
