Monitorización de caídas vs. monitorización de uptime
Usan el mismo mecanismo, un check programado desde fuera de tu infraestructura, pero la monitorización de caídas pone el énfasis en la velocidad de detección y la calidad de la alerta. Una herramienta puede “monitorizar uptime” y aun así hacer mal la detección de caídas si comprueba rara vez, alerta por ruido o envía avisos a nadie.
La pregunta práctica no es “¿comprueba mi sitio?”, sino “¿cuánto pasa entre que cae y una persona se entera?” y “¿esa alerta llega a alguien que puede actuar?”.
Qué causa realmente las caídas
La mayoría de caídas vienen de unas pocas causas: DNS, certificado TLS caducado, dominio caducado, hosting o servidor fallando, o un deploy malo. Cada una necesita un check ligeramente distinto: un ping de uptime detecta un servidor muerto, pero no un certificado que vencerá en tres semanas.
Por eso la monitorización de caídas bien hecha es un conjunto pequeño de checks: uptime, TLS, caducidad de dominio y DNS cubren gran parte de las causas reales.
Qué tan rápido es suficiente
La respuesta honesta es: antes de que tus usuarios lo noten y se quejen. Un intervalo de 5 minutos implica un peor caso de 5 minutos entre el inicio de una caída y su detección, razonable para la mayoría de sitios y el intervalo del plan Free de Holter.
La velocidad solo importa si la alerta llega a alguien. Un monitor que escribe en un canal que nadie mira, o en una bandeja filtrada a una carpeta, añade su propia latencia.
Errores que retrasan la detección
Comprobar desde una sola ubicación. Un único punto no distingue “el sitio está caído” de “esta ruta de red está fallando”; varias ubicaciones de sondeo lo descartan antes de alertar.
Alertar por el primer fallo. Produce tantos falsos positivos que la gente empieza a ignorarlos.
Sin dueño para la alerta. Una alerta en un sitio no vigilado equivale a no tener alerta.
Comprobar solo la homepage. Si checkout, login o una ruta de API fallan por separado, un check de homepage no lo verá.
Caídas que nunca tocan la página principal
No toda caída parece un sitio muerto. Un cron que deja de correr, una cola que muere en silencio o un backup nocturno que falla pueden durar días sin que falle ningún check externo, porque la homepage no cambió. Necesitan otro tipo de monitorización: un heartbeat, donde el trabajo hace check-in al terminar bien y se alerta si el check-in esperado no llega.
La monitorización que solo mira la puerta principal pierde toda esta categoría. El sitio puede verse sano para los visitantes mientras un backup deja de funcionar por debajo, y descubrirlo durante una emergencia real.
Después de la alerta: medir cuánto tardó de verdad
Detectar rápido es media tarea; la otra media es saber cuánto duró el incidente y qué tan rápido se detectó. El historial del monitor responde: cuándo ocurrió el primer check fallido, cuándo salió la alerta y cuándo se recuperó. Revisarlo permite ajustar umbrales e intervalos con datos reales.
Cómo lo hace Holter
Holter ejecuta checks externos de uptime, TLS, DNS y caducidad de dominio desde varias ubicaciones de sondeo, junto con monitores heartbeat entrantes para crons, colas y backups que deben hacer check-in en lugar de responder a una petición. Un incidente se abre cuando un check supera tu umbral de fallos consecutivos o falta un heartbeat esperado.
El plan Free cubre 5 monitores con checks cada 5 minutos y sin tarjeta, suficiente para poner detección real de caídas, externa y por heartbeat, en las URLs principales y trabajos en segundo plano de un sitio.
Holter vigila esto por ti: monitores externos y heartbeats para fallos silenciosos. Plan gratis: 5 monitores, comprobaciones cada 5 minutos, sin tarjeta.
Empezar a detectar caídas gratis