Qué hacer cuando Astrina deja de enviar alertas

¿Faltan todas las alertas de Astrina o solo falla una ruta de alerta?

Empieza con una pregunta: ¿falta toda alerta de Astrina o solo una ruta? Esa diferencia ahorra tiempo cuando intentas averiguar por qué no llegan las alertas de Astrina. Si el correo está en silencio pero un webhook sigue activándose, no estás ante una caída de toda la plataforma.

Elige un tipo de alerta, un canal y un destino. Por ejemplo, “caída de la base de datos” por correo es una sola ruta; “aviso de espacio en disco” a Slack es otra. Prueba cada ruta por separado, porque una bandeja rota y un webhook roto cuentan historias muy distintas sobre por qué las alertas Astrina no se reciben.

Si solo falla una ruta, el problema suele ser local. Una sola integración puede romperse mientras el resto sigue funcionando. Eso pasa a menudo con un canal de Slack renombrado o un alias de correo que ya no existe, y suele explicar los problemas con alertas de Astrina.

Si todas las rutas fallan a la vez, el panorama cambia rápido. Entonces debes revisar ajustes compartidos, un evento de origen que nunca se dispara o un cambio a nivel de cuenta. No des por hecho que el motor de alertas está roto solo porque una bandeja de entrada esté vacía.

Usa el nombre de la alerta exactamente como aparece en Astrina. Un solo error tipográfico en el nombre puede ocultar otra ruta. Un detalle pequeño, una gran diferencia.

¿Cambió algo en el sistema de destino o en las reglas de la bandeja de entrada?

Empieza mirando fuera de Astrina. Una bandeja puede renombrarse, un canal puede archivarse o un endpoint de webhook puede eliminarse sin aviso. Un solo cambio de administrador basta.

Para correo, revisa los filtros de spam, las reglas de reenvío y las bandejas deshabilitadas. Un filtro que mueve mensajes a una subcarpeta puede hacer que las alertas parezcan desaparecidas aunque sí hayan llegado. Es molesto, pero común.

Para herramientas de chat, confirma que el canal siga existiendo y que la app siga instalada. Algunos equipos rotan los permisos del espacio de trabajo cada mes. Después de eso, las alertas dejan de llegar al lugar que todos esperan.

Para webhooks, confirma que el servicio receptor siga aceptando la misma URL y el mismo método. Un cambio de ruta, una rotación de token o una nueva regla de firewall puede bloquear la alerta antes de que alguien la vea. Si tu equipo registra las integraciones en otro sitio, compara el destino actual con el último que funcionó correctamente.

Si necesitas una referencia rápida de los detalles de configuración de la API, la página de endpoints, autenticación y cuotas de Astrina es el lugar adecuado para revisar la forma de la petición antes de culpar a la entrega.

¿Sigue Astrina generando la alerta en el origen?

Ahora revisa la condición de origen en sí. Si ya no se supera un umbral, la alerta no se activará. Un aviso de disco al 92% no hace nada si la regla empieza en 95%.

Hazte una pregunta simple: ¿ocurrió el evento otra vez después de que la alerta dejara de llegar? Si el servidor nunca alcanzó el disparador, el mensaje “perdido” no está perdido en absoluto. Nunca se creó.

Comprueba la condición en bruto, no el mensaje. Un trabajo fallido, una caída de tráfico o un timeout deberían seguir apareciendo en los datos de origen si Astrina está vigilando la métrica correcta. Si esos datos están planos, probablemente la lógica de alerta está bien y lo que cambió fue la fuente.

Ten cuidado con los sistemas silenciosos. Un cron job puede detenerse sin un error visible. Un formulario puede dejar de recibir envíos después de un cambio en el front-end. En ambos casos, Astrina está esperando una señal que ya no llega.

Para monitorización específica de sitios web, compara el evento de origen con los patrones de tráfico usando la guía de verificación de tráfico del sitio web si la alerta depende de visitas o caídas de sesiones. Eso es más rápido que adivinar.

¿La alerta se está retrasando en lugar de perderse?

Sí. Los retrasos ocurren. Una cola puede saturarse, un servicio aguas abajo puede limitar las solicitudes o un reintento puede posponer la entrega unos minutos.

Ese momento importa. Si una alerta debería activarse de inmediato y otra puede reintentarse, ambas pueden parecer “desaparecidas” durante un corto periodo. Comprueba si la alerta llegó tarde antes de abrir un ticket.

La cola suele hacerse visible después de picos de tráfico. Un lote grande de eventos puede quedar detrás de trabajos anteriores. La alerta sigue en movimiento, solo que todavía no está donde esperas.

La limitación de velocidad puede parecerse mucho. Algunos destinos restringen cuántos mensajes aceptan en poco tiempo y luego ralentizan el resto. Si el receptor está aplicando rate limiting, Astrina puede necesitar reintentar.

Busca marcas de tiempo de entrega en los registros de Astrina. Compara el primer intento de envío con el reintento posterior. Una diferencia de 2 minutos es normal en algunas configuraciones; una de 2 horas indica otro problema.

¿La alerta fue suprimida en silencio por una regla o un filtro?

La supresión es fácil de pasar por alto porque no “falla” nada. El evento ocurre, pero Astrina decide no enviar la alerta. La deduplicación, las ventanas de silencio y el modo mantenimiento pueden hacer eso.

La deduplicación agrupa repeticiones. Si el mismo problema se activa 10 veces en 10 minutos, Astrina puede enviar una alerta y suprimir el resto. Eso es útil hasta que alguien espera un aviso nuevo por cada ocurrencia.

Las ventanas de silencio son aún más discretas. Un equipo puede silenciar alertas durante un despliegue y luego olvidar que la ventana sigue activa. Una casilla olvidada puede explicar una bandeja vacía a las 3:00 a.m.

El modo mantenimiento puede bloquear la entrega por diseño. El enrutamiento condicional también puede enviar las alertas a otro lugar, como otro canal del equipo. Si solo revisas un destino, puedes perderte la alerta aunque Astrina haya hecho exactamente lo que se le indicó.

Las reglas de supresión merecen una revisión directa, sobre todo después de cambios de configuración. Si la alerta debía haberse activado pero no lo hizo, el conjunto de reglas suele ser el primer sitio al que mirar.

Si gestionas alertas para un equipo mixto, astrina para propietarios de sitios web puede ayudar a los no ingenieros a entender por qué una ruta silenciada puede parecer una caída del sistema.

¿Qué registros o marcas de tiempo deberías comparar primero?

Usa el conjunto de evidencias más pequeño posible. No necesitas cada línea del registro. Empieza con cuatro marcas de tiempo: hora del evento, hora del intento de envío, hora del intento de entrega y hora de recepción en el destino, si está disponible.

Esa secuencia muestra el punto de ruptura. Si existe la hora del evento pero no aparece ningún intento de envío, Astrina nunca superó el disparador de origen. Si existe el intento de envío pero no aparece el intento de entrega, el problema está entre Astrina y el destino.

Si falta la hora de recepción en el destino, el último salto es el sospechoso. Si existe pero el usuario nunca vio el mensaje, entonces probablemente intervienen las reglas de la bandeja o los permisos del canal. Cadena corta, culpa clara.

Mantén la comparación reducida. Una alerta, una fecha, un destino. Eso facilita mucho ver si la alerta se detuvo en la generación, el transporte o la recepción.

Una tabla sencilla puede ayudarte a ordenarlo.

Una última cosa: compara las marcas de tiempo en la misma zona horaria. Un desfase de tres horas puede hacer que una alerta sana parezca ausente. Ese error arruina las tardes.

¿Cuándo deberías escalar el problema al soporte de Astrina o a tu administrador?

Escala después de haber revisado el evento de origen, el enrutamiento, los cambios en el destino y los ajustes de supresión. Si las cuatro cosas parecen normales y la alerta sigue sin llegar, el problema ya no es simple.

Lleva evidencia concreta. Incluye el nombre de la alerta, la fecha y la hora, el canal o destino, la última alerta que funcionó y cualquier texto de error que puedas copiar literalmente. Un equipo de soporte puede avanzar más rápido con seis datos que con una queja vaga.

Si cuentas con ayuda de un administrador, pídele que revise primero los cambios recientes. Un permiso actualizado, una ventana de silencio editada o una integración eliminada pueden romper una ruta que funcionaba todo el día de ayer. Ese es el tipo de cosa que la gente suele olvidar mencionar.

Cuando el problema afecta a más de un destino, indícalo claramente. Una sola bandeja fallida es un caso. Tres destinos fallidos pueden señalar un problema de configuración compartida. Respuesta distinta, responsable distinto.

Si necesitas comparar comportamientos de entrega relacionados, el artículo cómo arreglar el tráfico en vivo que falta es un buen complemento cuando el mismo sitio también pierde señales en tiempo real. Y si estás intentando entender los límites del sistema antes de escalar, revisa cómo comparar Astrina con Matomo para hacerte una idea de cómo las decisiones sobre el manejo de datos pueden alterar lo que se envía.

Envía la escalación solo después de tener una línea temporal limpia. Sin eso, la primera respuesta serán solo preguntas que podrías haber contestado tú mismo. Un registro ordenado ahorra mucho ida y vuelta.

Mantén el ticket breve, pero no vago. Di qué se detuvo, cuándo se detuvo y qué cambió alrededor del mismo momento. Eso basta para hacer avanzar el problema.

Si tu equipo mantiene varias rutas de alerta, pide al administrador que compruebe si una regla cambió globalmente o solo para una ruta. Esa diferencia importa porque un cambio global puede explicar por qué varias alertas desaparecieron a la vez, mientras que una edición específica de una ruta suele dejar intactas las demás.

No esperes una semana de silencio antes de escalar. Si las alertas de Astrina dejan de llegar después de un cambio conocido y los registros muestran intentos fallidos repetidos, ya tienes suficiente para transferir el problema con confianza.