1. Empieza con un monitor de disponibilidad ya existente y abre sus ajustes de alertas
Si ya tienes una comprobación en marcha, ya has recorrido la mitad del camino. Ahora no se trata de montar desde cero un sistema completo de monitorización de disponibilidad de un sitio web; se trata de convertir esa comprobación en algo que avise a la persona adecuada en el momento adecuado.
Abre el monitor que quieres seguir de cerca y busca los ajustes de alertas, las reglas de notificación o las opciones de incidentes. La etiqueta exacta puede variar, pero el objetivo es el mismo: conectar un monitor activo con una acción cuando aparezca una caída.
Ahí es donde configurar alertas de disponibilidad de Astrina paso a paso empieza a sentirse práctico. No estás rediseñando el monitor. Estás decidiendo qué debe pasar después de que el monitor falle dos veces, o cinco, o cuando tu equipo quiera que se emita la alerta.
Empieza solo con un servicio. Si tu página de inicio, la de inicio de sesión y la de pago fallan a la vez, un solo monitor basta para comenzar. Eso mantiene la primera alerta simple, y las alertas simples se leen.
Comprueba el nombre actual del monitor, la URL de destino y la frecuencia de ejecución antes de tocar las alertas. Una etiqueta como “Prod Login” es mejor que “Check 1”, porque tu bandeja de alertas será menos confusa a las 2:14 a. m.
2. Elige las condiciones de caída que deben activar una alerta
El núcleo de la configuración es el disparador. Necesitas umbrales de alerta para caídas que se ajusten al servicio, no una regla genérica copiada de otro sitio.
Un disparador habitual son los fallos consecutivos. Dos comprobaciones fallidas pueden ser suficientes para una pequeña herramienta interna, mientras que una página de pagos orientada al cliente puede necesitar tres o más antes de alertar. El número importa, porque un fallo aislado y momentáneo no debería despertar a un ingeniero de guardia, salvo que el servicio ya sea frágil.
Los picos en el tiempo de respuesta también pueden importar. Un sitio puede seguir devolviendo 200 OK y estar prácticamente roto si la página tarda demasiado en cargar, especialmente durante el proceso de compra. Lento no es lo mismo que caído, pero los usuarios a menudo viven ambas cosas como un fallo.
También merece la pena vigilar los patrones de códigos de estado. Una respuesta del tipo 500 suele requerir atención antes que un 404, mientras que un 401 en un panel privado puede significar simplemente que la página está protegida. El truco está en hacer coincidir el patrón de código con el comportamiento esperado del servicio.
Elige el disparador más específico que encaje con el servicio. Si el monitor es para una página de inicio sin inicio de sesión, un 403 normalmente debería investigarse. Si es para un entorno de pruebas, ese mismo código puede ser solo ruido. Una sola regla no sirve para todos los endpoints.
No pongas el umbral demasiado sensible. Un monitor que avisa al primer fallo puede volverse inútil en una semana. Tampoco lo pongas demasiado estricto. Si una caída real puede durar 10 minutos antes de que alguien se entere, el umbral es demasiado lento para tráfico orientado al cliente.
3. Configura los canales de notificación y dirige las alertas a las personas adecuadas
Elige a dónde debe llegar la alerta. El correo electrónico está bien para baja urgencia, pero el chat, los SMS u otro destino de notificación suele ser mejor para la respuesta activa ante incidentes. La idea es asegurarse de que alguien vea la alerta mientras la caída sigue ocurriendo, y por eso conviene definir bien tus alertas de monitorización web.
Dirige cada alerta al equipo que puede actuar sobre ella. Un error de base de datos no debería ir solo al chat de marketing. Un fallo en el pago no debería quedarse esperando en una bandeja general donde tres personas asumen que otra se encarga.
Deja explícita la cobertura fuera del horario laboral. Si el equipo diurno recibe la primera alerta y el nocturno la segunda, déjalo escrito en las notas del monitor. Si no, la alerta acabará en un callejón sin salida después del horario de oficina.
Un monitor puede enviar a más de un sitio, pero eso no significa que deba hacerlo. Dos canales bastan para muchos equipos: un responsable principal y un respaldo. Más destinos pueden generar un ruido del tipo equivocado.
Piensa en la persona que recibe el mensaje a la 1:00 a. m. Necesita el nombre del servicio, la URL que falla y el último estado conocido. “Algo está caído” no es una alerta; es un acertijo, especialmente si te preguntas cómo recibir alertas de caída del sitio de forma útil y accionable.
4. Separa las alertas de producción del ruido de mantenimiento y pruebas
Las alertas de producción necesitan su propio carril. El mantenimiento programado, las comprobaciones de staging y las ventanas de despliegue pueden generar falsos positivos si se mezclan en el mismo flujo de alertas. Ahí es donde una configuración ordenada ahorra tiempo.
Si un despliegue está programado para 15 minutos, silencia el monitor relacionado durante esa ventana. Si se comprueba staging cada 5 minutos, mantenlo en un grupo aparte para que no avise al equipo de producción. El objetivo no es ocultar problemas; es evitar que el ruido de pruebas parezca un daño real.
Esto es distinto de una configuración básica de monitorización de disponibilidad de un sitio web, donde la primera preocupación es simplemente si una página es accesible. Las alertas son más selectivas. Plantean una segunda pregunta: ¿debe interrumpirse a una persona ahora mismo?
Usa nombres que dejen clara la separación. “Prod API”, “Staging API” y “Maintenance Test” son mejores que tres etiquetas casi idénticas. A las 3 a. m., un nombre claro ahorra más tiempo que cualquier sistema ingenioso de nomenclatura.
Las ventanas de mantenimiento deben tener límite temporal. Si silencias una comprobación durante 2 horas y te olvidas de reactivarla, el sistema de alertas se habrá quedado ciego. Es un mal intercambio, incluso si el despliegue inicial salió bien.
Un pequeño apunte: los falsos positivos parecen inofensivos hasta que ocurren tres veces en una semana. Entonces todo el mundo empieza a ignorar la cuarta alerta. Ese es el verdadero coste.
5. Ajusta el tiempo de escalado para que las alertas de caída sean accionables
La escalada es el punto en que un monitor se convierte en un proceso de incidentes. Puedes retrasar la primera alerta, repetirla tras un intervalo fijo o pasarla a otro responsable si la caída continúa.
Empieza por decidir quién debe recibir la primera notificación. Esa persona debería poder actuar sin tener que buscar contexto. Si el primer responsable no puede cambiar el servicio, la alerta está dirigida al escritorio equivocado.
Después decide qué ocurre tras la primera alerta. Un recordatorio a los 10 minutos puede tener sentido para una caída persistente, mientras que una segunda ruta hacia un ingeniero de respaldo puede encajar mejor en un equipo pequeño que comparte las guardias. El tiempo debe reflejar lo rápido que suele responder tu equipo, no lo rápido que te gustaría que respondiera.
La escalada no es lo mismo que el spam. Dos notificaciones pueden ser útiles si la segunda llega a otra persona con otro nivel de autoridad. Seis copias al mismo buzón solo enseñan a la gente a dejar de leer.
Sé específico sobre la consecuencia de que la caída continúe. Si se pasa por alto la primera alerta, ¿la siguiente va a un responsable, a un teléfono de guardia o a un canal compartido de incidentes? Escribe la secuencia dentro de las notas del monitor para que nadie tenga que adivinar bajo presión.
Una regla ayuda aquí: si el servicio es orientado al cliente, la escalada debe ser más corta. Si es un informe interno que puede esperar, el tiempo puede ser más lento. Misma plataforma, distinta urgencia.
6. Verifica una alerta de principio a fin con una prueba de caída controlada
Antes de confiar en la alerta en producción, pruébala una vez de principio a fin. Tienes que confirmar tres cosas: que el monitor falla cuando debe, que el umbral se activa cuando debe y que la notificación llega a la persona correcta.
Usa una prueba controlada, no una caída real. Un cambio temporal de URL, un endpoint de prueba o una ventana de mantenimiento pueden ser suficientes para activar el monitor de forma segura. La idea es ver funcionar toda la cadena sin romper algo importante solo para demostrar un punto.
Este es el paso que muchos equipos se saltan. Luego el primer incidente real se convierte en la primera prueba real, y esa es una forma pésima de descubrir errores de enrutamiento.
Observa la línea de tiempo con atención. Si la comprobación falla a las 10:00, la alerta no debería aparecer a las 10:17 salvo que el umbral se haya configurado así a propósito. Si llega al chat equivocado, corrígelo antes del siguiente incidente, no después.
Anota lo que ocurrió durante la prueba. Una nota simple con el nombre del monitor, el disparador usado, el destinatario y cualquier retraso ayudará más adelante cuando alguien pregunte por qué una alerta se activó dos veces. El número 2 importa más que un recuerdo difuso.
Si todavía estás creando el monitor, quizá quieras configurar primero el agente. La ruta de configuración con * puede ayudar cuando la comprobación necesita una instalación nueva, y luego los ajustes de alertas pueden añadirse encima sin tener que adivinar.
7. Revisa el historial de alertas y ajusta los umbrales tras incidentes reales
Las primeras alertas te enseñan más que una semana de planificación. Revísalas después de incidentes reales y busca patrones: falsos positivos repetidos, alertas que llegaron demasiado tarde o alertas que fueron a parar al equipo equivocado.
Si un corte de red de 2 minutos activó una alerta, sube el umbral. Si una caída de 12 minutos produjo solo una notificación y ninguna escalada, acorta el retraso o añade una ruta de seguimiento. Cada incidente real te da un dato, y un solo dato ya puede justificar un pequeño cambio.
El ruido es el enemigo aquí. Demasiadas alertas de poco valor hacen que la gente tarde más en responder, y eso puede convertir una caída breve en una más larga. Muy pocas alertas producen el mismo efecto, pero desde el otro lado. El equilibrio correcto no es fijo para siempre.
Fíjate en los códigos de estado, la hora del día y el servicio afectado. Una página de inicio de sesión que falla dos veces entre semana puede merecer un umbral más estricto que la misma página durante un fin de semana con poco tráfico. El contexto importa porque el coste de la interrupción no es el mismo a todas horas.
Mantén el ciclo de revisión corto al principio. Tras las primeras 3 a 5 alertas, ajusta las notas del monitor, la lista de destinatarios y el tiempo de escalado si hace falta. Esa pequeña revisión puede evitar que una alerta ruidosa se convierta en parte de la vida diaria.
Si también sigues rutas de usuario relacionadas, como el proceso de compra, puede ayudar comparar lo que dice la alerta con lo que realmente vieron los usuarios. Una alerta a nivel de página y una vista a nivel de sesión suelen contar partes distintas de la misma historia, y la reproducción de sesiones de Astrina para revisar el checkout puede facilitar detectar esa diferencia.
Un último punto práctico: escribe los cambios de vuelta en el propio monitor, no solo en un hilo de chat. Un comentario en Slack desaparece al seguir desplazándose. El monitor permanece.
