Suivi des exceptions

Le suivi des exceptions est le cœur de Quiet Guard : chaque erreur levée par votre application est capturée, regroupée et suivie tout au long de son cycle de vie. Vous y accédez en ouvrant un projet dans le panel /app, onglet Incidents.

Comment fonctionne l'ingestion

Votre client envoie (POST) un payload d'exception à /api/v1/ingest, authentifié par la clé de projet. Le serveur le valide, applique le quota mensuel de votre équipe, puis le transmet à l'ingesteur. Un appel réussi renvoie 202 Accepted avec l'identifiant public de l'issue. La forme complète du payload est documentée dans la référence de l'API d'ingestion.

Chaque exception acceptée devient une occurrence. Les occurrences sont regroupées en issues.

Regroupement par empreinte en issues

Plutôt que de stocker des milliers d'erreurs identiques en lignes distinctes, Quiet Guard les regroupe. Une empreinte (fingerprint) déterministe est calculée à partir de :

• le projet,
• la classe de l'exception,
• le fichier (chemin normalisé), et
• la ligne.

Toutes les occurrences partageant une empreinte sont regroupées dans une seule issue, avec un compteur d'occurrences qu'aucun envoi simultané ne fait perdre, la date de première apparition et celle de la dernière.

Pourquoi normaliser le chemin ? Les outils de déploiement servent souvent l'application depuis un répertoire horodaté (par ex. /releases/20260628/...). L'empreinte élimine ce bruit, en conservant le chemin à partir du premier marqueur /app/, /src/ ou /vendor/, pour que la même erreur se regroupe d'un déploiement à l'autre au lieu de se fragmenter à chaque release.

Occurrences

Ouvrez une issue pour voir sa page de détail : la classe et le message regroupés, l'endroit où elle se produit, le nombre de fois où elle a été vue, et la liste des occurrences individuelles. Chaque occurrence porte sa propre trace, son contexte de requête, son environnement et sa release, capturés au moment où elle s'est produite.

Résoudre, ignorer, rouvrir

Chaque issue a un statut :

• Ouverte: active, nécessite une attention (par défaut pour une nouvelle issue).
• Résolue: vous l'avez corrigée ; elle sort de la liste active.
• Ignorée: du bruit que vous ne voulez pas traiter ; conservée mais mise en sourdine.

Vous passez d'un état à l'autre via les actions de la liste des issues et de la page de détail. Des filtres permettent de se concentrer, par exemple, sur les seules issues ouvertes.

Réouverture sur régression

Si une issue est résolue et que la même erreur survient à nouveau, Quiet Guard la traite comme une régression : l'issue est automatiquement repassée en ouverte à l'occurrence suivante, et une alerte issue.reopened est déclenchée vers les canaux de notification abonnés. Inutile de surveiller les issues résolues : si elles reviennent, vous serez prévenu.

Corrélation release → commit

C'est là que les données GitHub paient. Lorsqu'une occurrence porte une release (un SHA de commit, envoyé dans context.release) et que le projet est connecté à GitHub, Quiet Guard associe cette release au commit synchronisé exact. Depuis l'issue, vous pouvez sauter directement au commit qui a livré le code défectueux, bouclant la boucle de l'erreur vue en production à la modification qui l'a causée.

À noter : la corrélation de release ne se résout que lorsque la valeur de release est un SHA de commit hexadécimal et que le commit correspondant a été synchronisé depuis GitHub.

Flux de triage

L'onglet Issues d'un projet s'ouvre en vue de triage : le filtre de statut est préréglé sur Ouvert et tous les filtres sont visibles au-dessus du tableau. La colonne 24 h compte les occurrences de chaque incident sur la dernière journée, repérez la rafale en cours, pas l'incident bruyant de la semaine passée. Sélectionnez plusieurs incidents pour les résoudre ou les ignorer en une action.

Assigner des incidents

Assignez un incident à un membre de l'équipe depuis la liste ou depuis sa page. Le filtre Assignés à moi transforme la liste en pile de travail personnelle, idéal pour les agences qui répartissent les projets entre développeurs.

Journaux autour d'un événement

Si votre offre inclut les journaux applicatifs, la page d'un incident affiche les journaux enregistrés sur le même projet et environnement à ±5 minutes de la dernière occurrence, le « pourquoi » s'y cache souvent. Chaque ligne mène à l'entrée complète.

Recherche globale

Appuyez sur ⌘K / Ctrl+K n'importe où dans le panneau pour retrouver un incident par classe d'exception, message ou fichier, et un projet par nom. Avec le stockage chiffré, les messages scellés ne sont pas cherchables (par design) : la recherche s'appuie sur les métadonnées en clair.

Et ensuite

• Configurez les alertes pour que l'équipe soit prévenue des issues nouvelles et rouvertes.
• Ajoutez les logs applicatifs pour le contexte autour de chaque erreur.
• Activez le stockage chiffré si le contenu des exceptions doit rester privé au repos.