Alertas

Capturar los errores solo tiene interés si las personas adecuadas son avisadas. Quiet Guard envía alertas a través de canales de notificación por proyecto cuando se producen eventos significativos.

Canales de notificación

Cada canal pertenece a un proyecto y se gestiona desde la pestaña Alertas del proyecto en el panel /app. Un canal tiene un tipo, un destino y un conjunto de eventos suscritos. Se admiten tres tipos de canales:

Los canales de Slack y webhook pertenecen a los planes de pago, Indie y Studio. En Free el formulario rechaza esos dos tipos y las alertas salen por correo. Un canal creado en un plan de pago nunca se elimina si el equipo vuelve a Free: se conserva tal como usted lo configuró, lleva una insignia en la tabla y deja de emitir hasta que el plan vuelva a incluirlo. Las alertas por correo están en todos los planes, Free incluido.

Un canal puede activarse o desactivarse, y solo se dispara para los eventos a los que está suscrito.

Eventos suscritos

Al crear un canal, usted elige los eventos a los que debe reaccionar:

• issue.created: una issue completamente nueva se ha visto por primera vez.
• issue.reopened: una issue resuelta ha reaparecido (una regresión).
• vulnerability.detected: se ha encontrado una nueva vulnerabilidad de dependencia para el proyecto (vea Seguridad de dependencias).
• heartbeat.overdue: una tarea programada ha dejado de hacer ping (vea Heartbeats).
• uptime.down y uptime.recovered: la URL vigilada ha dejado de responder, y ha vuelto a responder (vea Monitorización de disponibilidad).
• ssl_expiring: el certificado TLS de la URL vigilada se acerca a su fecha de caducidad.

Un canal solo notifica si está activado y suscrito al evento desencadenante. Las alertas de issues se envían tras la persistencia de la ocurrencia; las alertas de vulnerabilidad se envían cuando un escaneo de dependencias encuentra nuevos hallazgos.

Webhooks protegidos contra SSRF

Los destinos webhook y Slack son URL que el servidor va a llamar. Para prevenir la falsificación de peticiones del lado del servidor (SSRF), cada webhook saliente se valida antes del envío:

• Las URL se comprueban con una regla de URL pública al registrar el canal: las direcciones privadas, de bucle local e internas se rechazan.
• El despachador resuelve el host y se niega a llamar a los rangos de red internos/reservados.
• Las redirecciones HTTP están desactivadas, para que una URL pública no pueda redirigir la petición hacia una URL interna.

Por qué importa: sin estas salvaguardas, un atacante capaz de definir un destino webhook podría apuntarlo a http://169.254.169.254/ o a un servicio interno. Quiet Guard bloquea esta clase de ataque en el registro y en el envío.

Qué contiene una alerta

Una alerta identifica el proyecto, el evento, y la issue o los hallazgos afectados, con un enlace de vuelta al panel de control.

Equipos cifrados: si el almacenamiento cifrado está activo, las alertas se generan del lado del servidor sin acceso a su frase secreta; por lo tanto solo pueden incluir metadatos y un enlace al panel de control, nunca el mensaje sellado ni la traza. Es deliberado: el conocimiento cero en reposo implica que la ruta de alerta tampoco puede leer su contenido.

Heartbeats de tareas programadas

Las excepciones señalan el código que falla ruidosamente; los heartbeats atrapan las tareas que fallan en silencio, un cron perdido, un scheduler mal configurado, un job desactivado y luego olvidado. Cada tarea programada hace ping a Quiet Guard tras su ejecución; cuando los pings se detienen, los canales suscritos a heartbeat.overdue son alertados una vez por avería. El concepto, la puesta en marcha y el ajuste tienen su propia página.

Alertas de disponibilidad y certificado

La sonda de disponibilidad activa dispara uptime.down / uptime.recovered en las transiciones (una alerta por caída, una por recuperación), y la vigilancia diaria del certificado dispara ssl_expiring a 14 y luego 3 días de la expiración. La sonda, el historial de latencia y la página de estado pública se tratan en la página de monitorización de disponibilidad.

Protección contra tormentas de alertas

Un despliegue fallido puede crear decenas de issues distintas en pocos minutos. Cada canal de notificación dispone de un presupuesto de alertas deslizante (10 alertas por 10 minutos por defecto, ajustable por el operador; 0 desactiva el límite): más allá, las alertas siguientes se suspenden y el canal recibe un único aviso de "alertas en pausa" con un enlace al panel de control. No se pierde nada, cada issue sigue registrándose y permanece visible.

Resumen semanal

Cada lunes por la mañana, el propietario de cada equipo recibe un resumen semanal por correo electrónico: nuevas issues, volumen de eventos, las tres issues más ruidosas con su número de ocurrencias, vulnerabilidades abiertas, heartbeats atrasados, consumo del mes con su proyección de fin de mes, y almacenamiento de las copias de seguridad. Las líneas no llevan ningún enlace profundo, solo un botón único hacia su panel. Las semanas tranquilas se omiten, nada de correos vacíos. El operador puede desactivar el resumen globalmente.