Qué debería disparar una alerta de caída
Empieza con fallos que los visitantes notarían directamente: la página principal no responde, login o checkout devuelven error, una API falla, DNS deja de resolver o el certificado TLS es inválido o está cerca de vencer.
Evita alertar por cada petición fallida. Un parpadeo de red desde una ubicación de sondeo puede ser ruido. Para la mayoría de sitios, dos o tres fallos consecutivos, preferiblemente confirmados desde más de una ubicación de sondeo, son una regla mejor antes de abrir incidente.
Quién debería recibir primero la alerta
Envía la primera alerta a quien pueda empezar el arreglo: fundador, freelancer de mantenimiento, canal de soporte de la agencia o ingeniero de guardia. Una bandeja compartida o Slack sirve solo si alguien es responsable de mirarlo.
Si nadie es dueño del destino, la alerta no existe en la práctica. El sitio seguirá siendo descubierto primero por un cliente; la herramienta solo habrá creado un registro con hora que nadie vio.
Una línea práctica de reintentos y escalado
Para un sitio normal de cara a clientes, comprueba cada 5 minutos, exige un pequeño umbral de fallos consecutivos y alerta cuando se cruce. Así detectas caídas reales en una ventana predecible sin avisar por cada fallo transitorio.
El escalado debe seguir el riesgo del negocio. Un sitio folleto puede avisar por email primero. Un checkout, API de pago o sitio de cliente con contrato debería ir a un canal más rápido como Slack, Discord o un webhook al sistema que el equipo ya mira.
Texto de alerta que acelera la respuesta
Una alerta útil dice qué falló, desde dónde se comprobó, cuándo empezó y qué esperaba ver el monitor. “Homepage devolvió 500 en dos checks consecutivos” es accionable. “Problema detectado en el sitio” no lo es.
Incluye contexto suficiente para evitar la primera ronda de adivinanzas: URL, código de estado, tiempo de respuesta, fallo TLS o DNS y enlace al historial del incidente. Durante una caída, la claridad importa más que una frase ingeniosa.
Cómo reducir falsos positivos
Usa fallos consecutivos, ubicaciones de sondeo y umbrales razonables de tiempo de respuesta. No fijes un umbral tan bajo que la variación normal se convierta en incidente. No monitorices una página que bloquea bots, requiere sesión o varía mucho por visitante salvo que tengas una afirmación clara de qué significa “sano”.
Revisa los primeros incidentes. Si todo es ruido, ajusta umbrales antes de que la gente silencie el canal. Si las alertas llegan después de quejarse los clientes, acorta el intervalo o envíalas a un lugar más visible.
Cómo maneja Holter las alertas de caída
Holter vigila URLs, TLS, DNS, caducidad de dominio y check-ins heartbeat desde fuera de tu infraestructura. Tú eliges canal y umbral de fallo, así un incidente se abre solo cuando el monitor tiene evidencia suficiente para merecer tu atención.
El plan Free cubre 5 monitores con checks cada 5 minutos y sin tarjeta, suficiente para poner alertas fiables en un sitio real: homepage, login o API, TLS, dominio y un heartbeat para el trabajo en segundo plano que los usuarios no ven.
Holter vigila esto por ti: monitores externos y heartbeats para fallos silenciosos. Plan gratis: 5 monitores, comprobaciones cada 5 minutos, sin tarjeta.
Crear una alerta fiable gratis