Alertes

Capturer les erreurs n'a d'intérêt que si les bonnes personnes en sont averties. Quiet Guard envoie des alertes via des canaux de notification par projet lorsque des événements significatifs se produisent.

Canaux de notification

Chaque canal appartient à un projet et se gère depuis l'onglet Alertes du projet dans le panel /app. Un canal a un type, une cible et un ensemble d'événements abonnés. Trois types de canaux sont pris en charge :

Les canaux Slack et webhook relèvent des forfaits payants, Indie et Studio. Sur Free, le formulaire refuse ces deux types et les alertes partent par e-mail. Un canal créé sur un forfait payant n'est jamais supprimé si l'équipe revient sur Free : il est conservé tel que vous l'avez configuré, porte un badge dans la table, et cesse d'émettre jusqu'à ce que le forfait le porte de nouveau. Les alertes par e-mail existent sur tous les forfaits, y compris Free.

Un canal peut être activé ou désactivé, et ne se déclenche que pour les événements auxquels il est abonné.

Événements abonnés

À la création d'un canal, vous choisissez les événements auxquels il doit réagir :

• issue.created: une toute nouvelle issue a été vue pour la première fois.
• issue.reopened: une issue résolue est réapparue (une régression).
• vulnerability.detected: une nouvelle vulnérabilité de dépendance a été trouvée pour le projet (voir Sécurité des dépendances).
• heartbeat.overdue: une tâche planifiée a cessé de pinguer (voir Heartbeats).
• uptime.down et uptime.recovered: l'URL surveillée a cessé de répondre, puis a répondu de nouveau (voir Surveillance de disponibilité).
• ssl_expiring: le certificat TLS de l'URL surveillée approche de sa date d'expiration.

Un canal ne notifie que s'il est activé et abonné à l'événement déclencheur. Les alertes d'issues sont envoyées après la persistance de l'occurrence ; les alertes de vulnérabilité sont envoyées lorsqu'un scan de dépendances trouve de nouveaux constats.

Webhooks protégés contre la SSRF

Les cibles webhook et Slack sont des URL que le serveur va appeler. Pour prévenir la falsification de requête côté serveur (SSRF), chaque webhook sortant est validé avant l'envoi :

• Les URL sont vérifiées par une règle d'URL publique lors de l'enregistrement du canal: les adresses privées, de bouclage et internes sont rejetées.
• Le distributeur résout l'hôte et refuse d'appeler les plages réseau internes/réservées.
• Les redirections HTTP sont désactivées, pour qu'une URL publique ne puisse pas rediriger la requête vers une URL interne.

Pourquoi c'est important : sans ces garde-fous, un attaquant pouvant définir une cible webhook pourrait la pointer vers http://169.254.169.254/ ou un service interne. Quiet Guard bloque cette classe d'attaque à l'enregistrement et à l'envoi.

Ce que contient une alerte

Une alerte identifie le projet, l'événement, et l'issue ou les constats concernés, avec un lien de retour vers le tableau de bord.

Équipes chiffrées : si le stockage chiffré est actif, les alertes sont générées côté serveur sans accès à votre phrase secrète ; elles ne peuvent donc inclure que des métadonnées et un lien vers le tableau de bord, jamais le message scellé ni la trace. C'est volontaire : le zéro-connaissance au repos implique que le chemin d'alerte ne peut pas lire votre contenu non plus.

Heartbeats de tâches planifiées

Les exceptions signalent le code qui échoue bruyamment ; les heartbeats attrapent les tâches qui échouent en silence, un cron perdu, un scheduler mal configuré, un job désactivé puis oublié. Chaque tâche planifiée pingue Quiet Guard après son exécution ; quand les pings s'arrêtent, les canaux abonnés à heartbeat.overdue sont alertés une fois par panne. Le concept, la mise en place et le réglage ont leur propre page.

Alertes uptime et certificat

La sonde uptime active déclenche uptime.down / uptime.recovered sur les transitions (une alerte par panne, une par rétablissement), et la surveillance quotidienne du certificat déclenche ssl_expiring à 14 puis 3 jours de l'expiration. La sonde, l'historique de latence et la page de statut publique sont couverts sur la page surveillance uptime.

Protection anti-tempête d'alertes

Un déploiement raté peut créer des dizaines d'incidents distincts en quelques minutes. Chaque canal de notification dispose d'un budget d'alertes glissant (10 alertes par 10 minutes par défaut, réglable par l'opérateur ; 0 désactive la limite) : au-delà, les alertes suivantes sont suspendues et le canal reçoit un seul avis « alertes en pause » avec un lien vers le tableau de bord. Rien n'est perdu, chaque incident continue d'être enregistré et reste visible.

Résumé hebdomadaire

Chaque lundi matin, le propriétaire de chaque équipe reçoit un résumé hebdomadaire par e-mail : nouveaux incidents, volume d'événements, les trois incidents les plus bruyants avec leur nombre d'occurrences, vulnérabilités ouvertes, heartbeats en retard, consommation du mois avec sa projection de fin de mois, et stockage des sauvegardes. Les lignes ne portent aucun lien profond, seulement un bouton unique vers votre tableau de bord. Les semaines calmes sont ignorées, pas d'e-mail vide. L'opérateur peut désactiver le résumé globalement.