Sazabi

npx add-mcp 'https://mcp.sazabi.com/mcp'

Observabilité et sécurité natives de l’IA

Démarrage rapide : https://docs.sazabi.com/get-started/quickstart

Commencer : npx @sazabi/cli start

Alertes autonomes, débogage conversationnel et intégrations avec les agents de programmation. Sazabi met en évidence les problèmes importants et fournit à votre équipe le contexte nécessaire pour les résoudre.

Ils nous font confiance

• Mastra
• Weave
• Sandstone
• Wajo
• Autumn
• Agree.com
• Inth
• Hoplite
• Taiga
• XMTP Labs

Sazabi est une plateforme d’observabilité et de sécurité native de l’IA destinée aux équipes qui livrent rapidement des logiciels. Elle relie les journaux de production au code, détecte les problèmes importants sans nécessiter de moniteurs conçus manuellement, recherche les causes profondes et transmet un contexte utile aux outils utilisés par les ingénieurs. Posez des questions en langage courant, comprenez ce qui a changé et laissez les agents de programmation exploiter ce contexte pour aider à résoudre les problèmes de production.

Utilisez Sazabi pour les alertes autonomes, le débogage conversationnel et les flux de travail des agents de programmation. Sazabi est conçu pour les équipes d’ingénierie qui doivent trouver et corriger les problèmes de production sans gérer une vaste collection de tableaux de bord et de moniteurs statiques. Découvrez le produit, les intégrations, les pratiques de sécurité et les ressources pour les développeurs afin de comprendre comment Sazabi s’intègre à votre pile.

Fonctionnalités

Détection sans intervention

Repérez les problèmes que vous n’aviez pas anticipés

Les moniteurs ne détectent que les défaillances que vous avez prévues. Sazabi surveille chaque journal et signale les autres problèmes, des pannes silencieuses et des utilisateurs frustrés aux agents qui déraillent, dès que vous vous connectez.

• Détection automatique : Repérez les changements dans vos journaux sans écrire de règles d’alerte.
• Analyse des causes profondes : Regroupez les erreurs associées et remontez jusqu’à leur code source.
• Correctifs suggérés : Fournissez aux ingénieurs et aux agents de programmation un plan pour résoudre chaque problème.

Surveillance de la sécurité

Sachez dès qu’une faille vous expose

Sazabi analyse votre code à la recherche de failles de sécurité et vous avertit dès qu’une nouvelle CVE concerne un élément que vous utilisez. Lorsque des botnets, des fraudes ou des intrus apparaissent dans vos journaux, votre équipe en est informée en temps réel.

• Analyse du code : Repérez les vulnérabilités dans vos dépôts connectés.
• Suivi des CVE : Sachez quand une nouvelle vulnérabilité affecte vos dépendances.
• Détection des menaces : Repérez les botnets, les fraudes et les activités suspectes dans vos journaux.

Recherche en langage courant

Des journaux conçus pour vos agents

Vos agents de programmation déboguent en lisant les journaux. Sazabi les conserve donc tous et permet de les rechercher rapidement. Le stockage est suffisamment peu coûteux pour que vous n’ayez jamais à choisir ce que vous devez supprimer.

• Recherche en langage courant : Posez une question et obtenez une réponse accompagnée des enregistrements de journal correspondants.
• Requêtes structurées : Recherchez des champs de journal et des motifs récurrents pour affiner une investigation.
• CLI et MCP : Permettez aux agents de programmation d’interroger les journaux de production depuis leurs propres outils.

Tableaux de bord toujours à jour

Créez des graphiques à partir de ce que vous journalisez déjà

Si une donnée figure dans vos journaux, vous pouvez l’afficher sur un tableau de bord en temps réel : latence p99, mémoire, requêtes lentes, inscriptions. Vous pouvez vous passer entièrement du pipeline de métriques.

• Tableaux de bord générés par l’IA : Décrivez ce que vous souhaitez suivre et transformez vos journaux en graphiques.
• Métriques basées sur les journaux : Créez des graphiques du volume des journaux, de la mémoire et du processeur à partir des données que vous envoyez déjà.
• Mises à jour en direct : Gardez les graphiques à jour à mesure que de nouveaux journaux arrivent.

Fonctionnement de Sazabi

1. Connectez GitHub et Slack : Installez les applications GitHub et Slack en quelques clics. Sazabi analyse votre base de code pour en comprendre le contexte et rejoint les canaux où votre équipe travaille déjà.
2. Envoyez les journaux : Transférez les journaux depuis les plateformes que vous utilisez déjà. Structurés ou non, Sazabi les accepte tels quels. Aucun schéma, aucune règle d’analyse ni aucun tableau de bord à créer.
3. Recevez des alertes : Sazabi surveille vos journaux pour détecter les anomalies, examine chacune d’elles à la lumière de votre code et transmet le problème à Slack, Microsoft Teams ou par e-mail, avec la cause profonde déjà identifiée.

Faites ressortir les problèmes à partir de centaines de signaux

Tentatives d’attaque

Anomalies d’authentification

Rafales d’échecs de connexion, bourrage d’identifiants, déplacements impossibles, réutilisation de session.

Type de problème : Attaque en cours (bourrage d’identifiants, balayage, tentatives d’exploitation.)

Bourrage d’identifiants visant 900 comptes

État : Ouvert

Description

Une tentative de connexion coordonnée teste des identifiants sur des centaines de comptes tout en changeant d’adresse source.

Ce qui s’est passé

Les journaux d’authentification contiennent 2,000 échecs de connexion visant 900 comptes. La même séquence de comptes apparaît depuis différentes adresses IP, contrairement aux erreurs dispersées observées lors des connexions normales. Ces échecs indiquent une tentative automatisée de prise de contrôle ; ils ne prouvent pas qu’un compte a été consulté.

Comment enquêter

Regroupez les tentatives par compte et empreinte de session, examinez les connexions réussies dans cet ensemble et limitez le débit du trafic abusif.

Charges utiles d’attaque

Tentatives d’injection SQL, de traversée de chemin, de SSRF ou d’injection de modèle dans les requêtes.

Type de problème : Attaque en cours (bourrage d’identifiants, balayage, tentatives d’exploitation.)

Sondes d’injection SQL visant un outil d’observabilité

État : Ouvert

Description

Des sondes d’injection SQL non authentifiées ont atteint la base de données par l’intermédiaire d’un outil d’observabilité auto-hébergé et ont échappé au système de suivi des erreurs de l’équipe.

Ce qui s’est passé

Une personne sans session a envoyé des sondes d’injection SQL à un outil d’observabilité auto-hébergé, qui les a transmises directement à sa base de données. Le système de suivi des erreurs de l’équipe ne les a jamais détectées ; elles ressemblaient à quelques requêtes ayant échoué.

Comment enquêter

Suivez le chemin de requête concerné et examinez les journaux de requêtes de la base de données pour repérer tout accès non autorisé. Vérifiez la version de l’outil exposé et limitez le trafic entrant pendant l’enquête.

Tentatives d’exploitation

Trafic correspondant à une exploitation connue visant votre pile.

Type de problème : Attaque en cours (bourrage d’identifiants, balayage, tentatives d’exploitation.)

Sondes visant un point de terminaison vulnérable

État : Ouvert

Description

Des requêtes ciblent le point de terminaison mentionné dans un nouvel avis de sécurité, ce qui soulève des questions sur l’exposition de l’application déployée.

Ce qui s’est passé

Les journaux d’accès montrent des sondes répétées dont la route et la forme de la charge utile correspondent à celles décrites dans l’avis. Ces requêtes contournent la navigation habituelle et accèdent directement au point de terminaison concerné. La correspondance du trafic établit une tentative d’exploitation, mais ne confirme ni la vulnérabilité du déploiement ni la réussite de l’exécution.

Comment enquêter

Comparez la version du paquet déployé et les routes activées avec les informations de l’avis, puis examinez les réponses et les effets en aval avant de décider s’il faut appliquer un correctif ou prendre des mesures de confinement.

Bots et extraction de données

Clients à haut débit, navigateurs sans interface graphique, adresses IP changeantes.

Type de problème : Abus et fraude (abus de promotions ou de parrainage, fausses inscriptions, spam, extraction de données.)

Répertoire en cours d’extraction

État : Ouvert

Description

Des clients automatisés parcourent le répertoire de l’entreprise dans l’ordre, générant une charge de lecture soutenue et collectant des données de profil en masse.

Ce qui s’est passé

Les requêtes provenant d’un réseau parcourent chaque page du répertoire à intervalles réguliers, sans navigation intermédiaire. Des adresses client changeantes partagent la même séquence de pages et la même forme de requête. Cette activité diffère de la navigation interactive et expose le répertoire à une collecte systématique.

Comment enquêter

Vérifiez quels champs sont accessibles publiquement, regroupez les clients selon leur comportement et appliquez des limites de débit propres au répertoire sans bloquer la navigation normale.

Accès suspect

Anomalies d’accès

Un acteur lit beaucoup plus de données que d’habitude ou parcourt les identifiants dans l’ordre.

Type de problème : Accès suspect (comptes compromis, abus interne, exfiltration de données.)

Enregistrements lus dans l’ordre

État : Ouvert

Description

Un compte authentifié énumère des milliers d’enregistrements au lieu de suivre son parcours de navigation habituel.

Ce qui s’est passé

Le compte demande les identifiants d’enregistrement de 1 à 5,000 dans l’ordre. Les lectures réussies se poursuivent sur des enregistrements que la session n’a pas atteints par la recherche ou la navigation. Cela indique une collecte en masse et justifie de vérifier la portée des accès avant de supposer que chaque enregistrement renvoyé était autorisé.

Comment enquêter

Examinez la session, la charge de travail attendue et les décisions d’autorisation au niveau des enregistrements. Révoquez l’accès s’il n’était pas autorisé et identifiez les enregistrements renvoyés.

Modifications des privilèges

Nouveaux administrateurs, élévations de rôle, nouvelles clés API.

Type de problème : Accès suspect (comptes compromis, abus interne, exfiltration de données.)

Rôle d’administrateur accordé à 3 h

État : Ouvert

Description

Un compte a reçu des privilèges d’administrateur depuis un lieu inhabituel, en dehors de son activité normale, créant ainsi une nouvelle voie d’accès aux opérations privilégiées.

Ce qui s’est passé

La piste d’audit enregistre l’octroi d’un rôle d’administrateur à 3 h depuis un lieu absent des sessions précédentes de l’acteur. Les accès ultérieurs utilisent le nouveau rôle. Cette attribution peut correspondre à une opération de maintenance légitime, mais son auteur, son horaire et sa portée doivent être vérifiés avant de faire confiance à ce privilège.

Comment enquêter

Confirmez l’attribution auprès du propriétaire du compte, examinez la session qui l’a autorisée et passez en revue les actions privilégiées ultérieures. Révoquez le rôle s’il n’a pas été approuvé.

Sortie de données inhabituelle

Exportations volumineuses ou réponses destinées à un seul acteur.

Type de problème : Accès suspect (comptes compromis, abus interne, exfiltration de données.)

Exportation 50 fois plus volumineuse que d’habitude

État : Ouvert

Description

Une exportation transfère beaucoup plus de données que ce compte n’en récupère habituellement, ce qui laisse envisager un accès massif accidentel ou non autorisé.

Ce qui s’est passé

Une réponse CSV est 50 fois plus volumineuse que les exportations habituelles du compte. La requête supprime les filtres utilisés dans les exportations précédentes et renvoie un ensemble d’enregistrements beaucoup plus large. Ce changement de taille établit une sortie de données inhabituelle ; l’autorisation et la portée prévue doivent encore être vérifiées.

Comment enquêter

Comparez les filtres de l’exportation, les champs renvoyés et les autorisations du compte avec la tâche demandée. Vérifiez la destination et révoquez la session si l’exportation n’était pas autorisée.

Agents malveillants

Des agents d’IA, les vôtres ou ceux d’un tiers, agissent en dehors de leur périmètre habituel.

Type de problème : Comportement inapproprié d’un agent (agents d’IA agissant hors périmètre, injection de prompt, boucles incontrôlées.)

Agent d’assistance appelant un point de terminaison d’administration

État : Ouvert

Description

Un agent d’assistance invoque une opération administrative qui ne fait pas partie des outils et du périmètre utilisés pour ses tâches d’assistance habituelles.

Ce qui s’est passé

Les journaux d’appels d’outils montrent que l’agent a atteint un point de terminaison d’administration qu’il n’avait jamais utilisé auparavant. L’appel fait suite à un contenu fourni par un client plutôt qu’à une instruction d’un opérateur. Cette séquence soulève la possibilité d’un dépassement de périmètre ; la réponse et le journal d’audit doivent permettre d’établir si l’opération a réellement modifié quoi que ce soit.

Comment enquêter

Examinez le contenu déclencheur, les arguments de l’outil et le résultat de l’autorisation. Limitez les outils de l’agent à son périmètre d’assistance et exigez une approbation pour les actions administratives.

Vulnérabilités

Secrets ou données personnelles dans les journaux

Jetons, clés, adresses e-mail ou numéros d’identification écrits dans les journaux.

Type de problème : Exposition (une CVE qui vous concerne, un chemin de code vulnérable, une mauvaise configuration, des secrets divulgués.)

Clé API affichée dans une erreur

État : Ouvert

Description

Un gestionnaire d’erreurs copie un identifiant dans les données de diagnostic, l’exposant ainsi aux systèmes et aux personnes ayant accès aux journaux.

Ce qui s’est passé

Une requête sortante ayant échoué inclut sa clé API dans le message d’erreur consigné. La valeur est propagée avec l’exception au lieu d’être masquée à la frontière de journalisation. Toute personne pouvant lire cet enregistrement pourrait réutiliser la clé jusqu’à sa révocation.

Comment enquêter

Révoquez la clé exposée, identifiez où l’enregistrement a été transmis et conservé, et masquez les identifiants avant de sérialiser les erreurs de requête.

Nouvel avis vous concernant

Une CVE récemment publiée correspond à vos dépendances ou à votre environnement d’exécution (via cve.now).

Type de problème : Exposition (une CVE qui vous concerne, un chemin de code vulnérable, une mauvaise configuration, des secrets divulgués.)

Un nouvel avis correspond à votre fichier de verrouillage

État : Ouvert

Description

Un avis récemment publié concernant un framework inclut la version épinglée dans le fichier de verrouillage de l’application, ce qui nécessite de vérifier l’exposition de la version déployée. Ce qui s’est passé

La plage de versions concernées indiquée dans l’avis correspond à la dépendance du framework résolue. La correspondance dans le fichier de verrouillage identifie un artefact potentiellement vulnérable, mais ne montre pas si la fonctionnalité concernée est activée ou accessible. Le build déployé et sa configuration des routes déterminent l’exposition réelle.

Comment enquêter

Vérifiez la version déployée et la fonctionnalité concernée, examinez les mesures d’atténuation de l’avis, puis passez à une version corrigée et testez la route concernée.

Code à risque

L’analyse du code signale les contrôles d’authentification manquants, les contournements de l’authentification ou les risques d’injection dans les nouveaux commits.

Type de problème : Exposition (une CVE qui vous concerne, un chemin de code vulnérable, une mauvaise configuration, des secrets divulgués.)

Fichiers de l’hôte divulgués dans les erreurs de déploiement

Statut : Ouvert

Description

Des échecs de déploiement ont exposé aux utilisateurs des fichiers de l’hôte du builder via des messages d’erreur qui semblaient être de simples erreurs d’analyse.

Ce qui s’est passé

Un builder de déploiement a lu des fichiers sur son propre hôte et les a renvoyés aux utilisateurs dans des messages d’erreur de déploiement, notamment du contenu de type /etc/passwd. À première vue, il s’agissait de déploiements échoués avec une erreur d’analyse.

Comment enquêter

Suivez le chemin par lequel les entrées de build peuvent accéder aux fichiers de l’hôte et aux sorties d’erreur. Examinez les limites d’extraction des fichiers et supprimez le contenu des fichiers de l’hôte des erreurs visibles par les utilisateurs.

Chaîne d’approvisionnement

Une dépendance change de propriétaire, fait l’objet d’une attaque par typosquatting ou est signalée comme malveillante.

Type de problème : Exposition (une CVE qui vous concerne, un chemin de code vulnérable, une mauvaise configuration, des secrets divulgués.)

Version de package compromise

Statut : Ouvert

Description

Une version d’une dépendance a été signalée comme compromise, et le fichier de verrouillage indique qu’elle pourrait être incluse dans les builds de l’application.

Ce qui s’est passé

La version du package signalée correspond à la dépendance résolue, et pas seulement à une plage de versions permissive. Les enregistrements de build doivent établir où cette version a été installée et si son code ou ses scripts d’installation ont été exécutés. Cette correspondance crée un risque d’exposition sans prouver que des identifiants ou des données ont été dérobés.

Comment enquêter

Identifiez les builds concernés, comparez le package à la version de confiance, remplacez-le et ne faites tourner les identifiants que si leur exécution a pu les exposer.

Modèles de journaux

Événement disparu

Un événement qui se produit normalement a cessé, alors que le trafic reste normal.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués.)

Les soumissions de candidatures ont cessé d’arriver

Statut : Ouvert

Description

Les événements de soumission de candidature ont cessé alors que les utilisateurs continuent d’accéder au formulaire, ce qui suggère que des opérations sont perdues sans erreur explicite.

Ce qui s’est passé

L’événement « Application submitted » disparaît après 14 h 14, alors que les consultations du formulaire et les tentatives de soumission continuent. L’événement de fin habituel ne suit plus ces tentatives. Le trafic semble normal, mais l’absence de cette transition signifie que les candidatures n’atteignent peut-être pas leur état enregistré.

Comment enquêter

Suivez une tentative de soumission à travers la validation, la persistance et l’émission de l’événement. Comparez les candidatures enregistrées aux tentatives pour distinguer une lacune dans les journaux des soumissions perdues.

Variation de volume

Le taux d’un événement augmente ou diminue bien au-delà de son profil habituel.

Type de problème : Abus et fraude (abus de promotions ou de parrainage, fausses inscriptions, spam, scraping.)

Pic de réinitialisations de mot de passe

Statut : Ouvert

Description

Les demandes de réinitialisation de mot de passe dépassent largement leur niveau hebdomadaire habituel, augmentant la charge des e-mails et risquant d’inonder les propriétaires de comptes de messages indésirables.

Ce qui s’est passé

Les événements d’envoi d’e-mails de réinitialisation sont six fois plus nombreux que leur taux habituel du mardi, tandis que le trafic normal de connexion reste proche de son niveau de référence. Des comptes cibles récurrents et des séquences de demandes similaires expliquent une grande partie de cette hausse. Cela indique un abus ou une boucle de nouvelles tentatives accidentelle plutôt qu’une croissance générale du nombre d’utilisateurs.

Comment enquêter

Regroupez les demandes par compte cible et par initiateur, recherchez une boucle de nouvelles tentatives côté client et imposez des limites de réinitialisation par compte pour le trafic abusif.

Séquence rompue

A est normalement suivi de B ; désormais, A se produit sans B.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués.)

Les téléversements n’aboutissent jamais

Statut : Ouvert

Description

Les demandes de téléversement commencent normalement, mais n’atteignent pas leur étape de fin, rendant les fichiers indisponibles alors que les utilisateurs ont lancé le transfert.

Ce qui s’est passé

Les enregistrements « Upload started » continuent d’arriver, mais leurs identifiants de requête ne correspondent à aucun événement « upload complete ». Les événements de fin manquants se concentrent après le transfert vers le stockage. Les utilisateurs attendent un fichier qui n’a pas été finalisé, sans qu’une erreur correspondante ne soit signalée par l’application.

Comment enquêter

Suivez les identifiants de téléversement concernés dans le stockage et la finalisation. Recherchez les téléversements multiparties abandonnés, les rappels ayant échoué et l’absence de gestion des délais d’expiration ou des erreurs.

Changement d’ordre ou de timing

Les étapes se produisent dans le désordre ou avec des intervalles plus longs.

Type de problème : Intégrité des données (écritures perdues, doublons, corruption, enregistrements incohérents.)

Webhooks traités avant la création de leurs enregistrements

Statut : Ouvert

Description

Le traitement des webhooks entre en concurrence avec la création de l’enregistrement qu’il met à jour, ce qui permet de rejeter un événement pourtant valide comme s’il manquait des données.

Ce qui s’est passé

Les gestionnaires de webhooks recherchent un enregistrement avant que la transaction de création correspondante ne soit validée. La recherche ne renvoie rien, mais une lecture ultérieure trouve l’enregistrement sans mise à jour du webhook. L’ordre des événements laisse l’état local en retard sur celui du fournisseur, même si les deux requêtes aboutissent.

Comment enquêter

Faites correspondre la réception des webhooks aux validations des transactions, conservez les événements sans correspondance pour les réessayer et assurez-vous que leur rejeu est sans risque une fois l’enregistrement cible créé.

Dérive des champs

Les valeurs des événements changent : nouvelles catégories, valeurs nulles, chaînes vides, tailles inhabituelles.

Type de problème : Intégrité des données (écritures perdues, doublons, corruption, enregistrements incohérents.)

Écritures sans leur entreprise

Statut : Ouvert

Description

Une partie des écritures perd son association à l’entreprise, créant des enregistrements qui ne peuvent pas être attribués ou récupérés de manière fiable dans le périmètre attendu.

Ce qui s’est passé

Le champ company_id est null pour 3 % des écritures qui contenaient auparavant une valeur. Ces enregistrements partagent un chemin d’entrée qui omet le contexte de l’entreprise avant la persistance. Les écritures aboutissent, mais les lectures ultérieures limitées à l’entreprise ne peuvent plus les trouver dans la collection attendue.

Comment enquêter

Suivez la transmission du contexte de l’entreprise dans ce chemin d’écriture, rejetez les champs de propriété obligatoires manquants et identifiez les enregistrements concernés avant toute tentative de réparation ciblée.

Hausse de cardinalité

Un champ présente soudainement beaucoup plus de valeurs distinctes.

Type de problème : Risque de capacité (signalement d’une limite avant qu’elle ne soit atteinte.)

Multiplication des clés de cache

Statut : Ouvert

Description

Le cache crée de nouvelles clés pour des requêtes par ailleurs similaires, réduisant la réutilisation et augmentant la pression sur le stockage.

Ce qui s’est passé

Des milliers de clés de cache distinctes apparaissent chaque minute pour le même petit ensemble de routes. Les clés varient selon un suffixe propre à chaque requête, de sorte que les requêtes répétées ne trouvent pas les entrées qui devraient être réutilisables. L’ensemble croissant de clés augmente l’utilisation de la mémoire tout en transférant davantage de travail au service sous-jacent.

Comment enquêter

Comparez l’ancienne et la nouvelle construction des clés, supprimez les champs propres aux requêtes qui n’auraient pas dû être inclus et vérifiez l’expiration avant de nettoyer les entrées inaccessibles.

Formulation discrète d’un échec

Des événements décrivent un échec, mais sont consignés au niveau info ou debug.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués.)

La mise à jour des tarifs a ignoré le plus gros compte

Statut : Ouvert

Description

Une tâche de tarification a considéré le compte ignoré comme un traitement terminé avec succès, laissant les utilisateurs du plus gros compte avec les anciens coûts en crédits.

Ce qui s’est passé

Une tâche appliquant des changements de tarification a ignoré le plus gros compte à cause d’une limite codée en dur, puis a signalé « completed ». L’omission a été consignée au niveau info, si bien que les utilisateurs de ce client ont continué à payer les anciens coûts en crédits.

Comment enquêter

Examinez la limite et la gestion des comptes ignorés, relancez la mise à jour pour le compte exclu et vérifiez les tarifs appliqués avant d’enregistrer la fin du traitement.

Tempête de nouvelles tentatives

La même opération est réessayée en boucle serrée.

Type de problème : Échec d’une tâche en arrière-plan (travail planifié manqué, dupliqué, bloqué ou vide.)

Tâche réessayée en boucle serrée

Statut : Ouvert

Description

Un worker en arrière-plan réessaie sans cesse les mêmes enregistrements en échec sans progresser, consommant une capacité dont d’autres tâches ont besoin.

Ce qui s’est passé

Une tâche tente de traiter chaque enregistrement concerné 30 fois en boucle serrée. L’erreur et l’entrée restent inchangées entre les tentatives, sans délai croissant. Ces échecs répétés occupent le worker au lieu de laisser les enregistrements indépendants avancer ou de signaler le travail bloqué.

Comment enquêter

Déterminez si l’erreur répétée est temporaire ou permanente, appliquez un délai exponentiel plafonné et placez les enregistrements ayant épuisé leurs tentatives dans un état d’échec pouvant être examiné.

Rupture de corrélation

Deux services qui évoluent normalement de concert divergent.

Type de problème : Échec d’une tâche en arrière-plan (travail planifié manqué, dupliqué, bloqué ou vide.)

Les workers ne suivent plus le rythme

Statut : Ouvert

Description

Le trafic de l’API augmente sans hausse correspondante du nombre de tâches terminées par les workers, ce qui suggère que le travail accepté n’atteint plus la file d’attente ou n’en sort plus.

Ce qui s’est passé

L’API continue d’accepter des requêtes tandis que le nombre de tâches terminées par les workers reste stable. Auparavant, ces deux nombres évoluaient ensemble. Cette divergence signifie que les réponses positives de l’API ne prouvent plus que le travail en arrière-plan demandé a été effectué, et qu’une défaillance de la file d’attente ou de la distribution peut être masquée entre les deux.

Comment enquêter

Comparez les nombres de tâches acceptées, mises en file d’attente, démarrées et terminées par identifiant de tâche afin de localiser la rupture avant de rejouer ou de mettre à l’échelle le travail.

Nouvel événement

Un type d’événement qui n’est jamais apparu auparavant.

Type de problème : Régression (comportement dégradé par un déploiement ou un changement de configuration précis.)

Brouillons ignorés après le déploiement

Statut : Ouvert

Description

Un nouveau chemin d’enregistrement ignore les brouillons verrouillés après une version, laissant les modifications des utilisateurs non appliquées sans lever d’exception.

Ce qui s’est passé

Le message « skipping save, draft locked » apparaît pour la première fois après le déploiement. Les requêtes concernées ne produisent pas l’événement habituel de brouillon enregistré, tandis que les lectures ultérieures affichent toujours la révision précédente. La nouvelle branche empêche l’enregistrement au lieu de simplement ajouter des journaux de diagnostic.

Comment enquêter

Examinez le contrôle de verrouillage introduit par la version, inspectez le nettoyage des verrous obsolètes et vérifiez qu’un enregistrement refusé est clairement signalé à l’utilisateur.

Comportement des utilisateurs

Action sans effet

Un clic sans requête serveur, ou une requête sans résultat persistant.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués.)

Écran connecté, aucun jeton

Statut : Ouvert

Description

Le parcours de connexion du compte affichait une réussite alors que son jeton OAuth n’avait jamais été enregistré, rendant la connexion incapable de s’authentifier.

Ce qui s’est passé

Un utilisateur qui connectait un compte a vu le message « connected », mais le jeton OAuth n’a jamais été enregistré. Un rappel en double l’a redirigé vers la page de réussite alors que la requête initiale échouait en arrière-plan.

Comment enquêter

Examinez ensemble les résultats des rappels initial et dupliqué. Ne signalez la réussite de la connexion qu’une fois le jeton enregistré, puis reconnectez les comptes concernés.

Clics répétés et frénétiques

Le même contrôle est cliqué encore et encore.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués.)

Les utilisateurs martèlent le bouton Save

Statut : Ouvert

Description Les utilisateurs appuient plusieurs fois sur Enregistrer parce que le formulaire ne confirme pas si leurs modifications ont été acceptées, ce qui les incite à réessayer et risque de dupliquer le travail.

Ce qui s’est passé

Le même contrôle est cliqué cinq fois en dix secondes au cours d’une session. La première requête reste en attente tandis que les clics suivants lancent d’autres requêtes, et aucun état de réussite ou d’échec ne remplace le formulaire. Ce schéma d’interaction suggère un enregistrement bloqué ou une absence de retour d’information.

Comment enquêter

Suivez la première requête d’enregistrement, affichez ses états d’attente et d’échec, et empêchez les soumissions en double tout en vérifiant que les nouvelles tentatives restent sûres.

Abandon dans l’entonnoir

Le taux de conversion baisse d’une étape à l’autre.

Type de problème : Rupture du parcours métier (baisse d’un indicateur clé due à une cause technique).

Le taux de finalisation des inscriptions est tombé à 50 %

Statut : Ouvert

Description

Davantage de personnes commencent leur inscription qu’elles ne la terminent, la perte se concentrant entre l’envoi du formulaire et la création du compte.

Ce qui s’est passé

Le taux de finalisation des inscriptions passe de 80 % à 50 %, tandis que le nombre de sessions commencées reste comparable. Les sessions atteignent l’étape d’envoi, mais aucun événement de création de compte n’est enregistré. Cette baisse reflète un parcours d’intégration inachevé, et non simplement une diminution du nombre de visiteurs sur le site.

Comment enquêter

Comparez les traces des inscriptions réussies et échouées à la première étape manquante, puis segmentez les résultats selon la validation, la version du client et le fournisseur d’identité.

Boucles de navigation

Les utilisateurs font des allers-retours entre les mêmes pages.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués).

Les utilisateurs sont bloqués entre les paramètres et la facturation

Statut : Ouvert

Description

Les utilisateurs sont renvoyés entre les paramètres et la facturation sans atteindre l’écran nécessaire pour terminer leur tâche.

Ce qui s’est passé

Les sessions suivent à plusieurs reprises le parcours paramètres → facturation → paramètres, sans événement de finalisation entre les deux. Chaque destination renvoie l’utilisateur en fonction d’une vérification différente de l’état du compte. Cette boucle empêche l’accès aux commandes de facturation, même si les deux routes renvoient des réponses réussies.

Comment enquêter

Comparez les conditions d’accès et l’état du compte utilisés par les deux routes. Résolvez les redirections contradictoires et vérifiez le parcours à partir d’une session concernée.

Impasses

Les sessions se terminent sur des états d’erreur, des écrans vides ou des indicateurs de chargement sans fin.

Type de problème : Dysfonctionnement du frontend (fonctionne mal dans un navigateur, sur un appareil ou dans une version de l’application spécifique).

L’indicateur de chargement du tableau de bord ne disparaît jamais

Statut : Ouvert

Description

Le tableau de bord reste en cours de chargement jusqu’à ce que les utilisateurs quittent la page, masquant une requête bloquée au lieu d’afficher du contenu exploitable ou une erreur.

Ce qui s’est passé

Les sessions affichent l’indicateur de chargement du tableau de bord pendant plus de 30 secondes avant la fermeture de l’onglet. La requête initiale de données ne produit jamais d’état de réussite ou d’échec affiché. Les autres ressources de la page se chargent normalement, ce qui circonscrit le problème au chargement des données plutôt qu’à une panne complète de la page.

Comment enquêter

Examinez la requête en attente et la limite d’erreur du composant, ajoutez un état d’expiration récupérable et vérifiez qu’un échec de chargement permet à l’utilisateur de réessayer.

Erreurs côté client

Exceptions JavaScript, échecs de requêtes fetch, erreurs d’hydratation.

Type de problème : Régression (comportement dégradé par un déploiement ou une modification de configuration spécifique).

Nouvelle TypeError après la mise en production

Statut : Ouvert

Description

Une page récemment mise en production déclenche une TypeError pendant le rendu, empêchant les utilisateurs concernés d’accéder à son contenu.

Ce qui s’est passé

L’exception apparaît pour la première fois dans les sessions utilisant la nouvelle version et présente le même emplacement dans la pile d’appels. Le code défaillant lit une propriété d’un objet de réponse manquant avant le rendu de la page. Les requêtes peuvent réussir au niveau réseau alors que l’interface n’affiche toujours pas leur résultat.

Comment enquêter

Associez la pile d’appels au code source mis en production, examinez la structure de la réponse dans les sessions concernées et gérez la valeur manquante avant le rendu.

Régression des indicateurs Web Vitals

Le chargement des pages et leur réactivité se dégradent.

Type de problème : Dégradation des performances (pages, tâches ou API plus lentes, soudainement ou progressivement).

La latence des interactions a doublé

Statut : Ouvert

Description

Les interactions sur une page mettent nettement plus de temps à produire un retour visuel, même si le serveur répond toujours normalement.

Ce qui s’est passé

La latence des interactions sur la page double par rapport à sa valeur de référence précédente. Les traces du navigateur attribuent l’attente supplémentaire à une longue tâche sur le thread principal après la saisie de l’utilisateur, tandis que les temps réseau restent comparables. Les utilisateurs constatent une interface retardée sans erreur API ni pic de latence correspondant.

Comment enquêter

Analysez la longue tâche qui suit la saisie, comparez le chemin de rendu modifié et déplacez ou réduisez le travail synchrone avant de mesurer à nouveau la réactivité.

Comportement propre à un segment

Un seul navigateur, système d’exploitation, version de l’application, région ou client est concerné.

Type de problème : Dysfonctionnement du frontend (fonctionne mal dans un navigateur, sur un appareil ou dans une version de l’application spécifique).

Échec du paiement sur Safari 18

Statut : Ouvert

Description

Le paiement échoue dans les sessions Safari 18, alors que les utilisateurs d’autres navigateurs terminent le même parcours, ce qui masque la régression dans le taux de réussite global.

Ce qui s’est passé

Les échecs de paiement se concentrent dans les sessions Safari 18. Les traces côté client s’arrêtent avant la requête de paiement, tandis que le même panier atteint l’étape du paiement dans les autres navigateurs. Ce problème propre au navigateur empêche les achats sans provoquer d’échec correspondant chez le fournisseur de paiement.

Comment enquêter

Reproduisez l’interaction défaillante dans Safari 18, examinez la compatibilité des API du navigateur et les exceptions côté client, puis vérifiez le correctif dans les navigateurs où le parcours fonctionne.

Déploiements et configuration

Changement après déploiement

Tout autre signal qui apparaît dans les minutes suivant un déploiement et qui est lié au commit.

Type de problème : Régression (comportement dégradé par un déploiement ou une modification de configuration spécifique).

L’entonnoir a chuté juste après la mise en production

Statut : Ouvert

Description

Une mise en production coïncide avec une baisse du nombre de parcours utilisateur terminés et l’apparition d’un nouvel événement de rejet, ce qui relie la régression à une modification du chemin de requête.

Ce qui s’est passé

Quatre minutes après la mise en production, un événement de validation jusque-là inédit apparaît et le taux de finalisation de l’entonnoir baisse. Les sessions en échec atteignent la même étape et portent le nouvel identifiant de build ; les sessions utilisant le build précédent aboutissent toujours. Cette comparaison indique que le chemin mis en production est le prochain élément à examiner.

Comment enquêter

Comparez la validation et le traitement des réponses entre les deux builds. Reproduisez le problème avec la saisie concernée et évaluez un retour arrière tout en isolant la modification.

Modification de configuration ou de feature flag

Le comportement change après une modification de feature flag, de variable d’environnement ou d’infrastructure.

Type de problème : Régression (comportement dégradé par un déploiement ou une modification de configuration spécifique).

Le déploiement progressif du flag fait échouer les enregistrements

Statut : Ouvert

Description

Un feature flag activé partiellement fait passer une partie des enregistrements par un chemin défaillant, tandis que le reste du trafic continue de fonctionner normalement.

Ce qui s’est passé

Le flag est activé pour 10 % du trafic, et les enregistrements échoués représentent la même proportion. Les enregistrements d’échec appartiennent au groupe pour lequel le flag est activé ; le groupe pour lequel il est désactivé continue de persister les modifications. La limite du déploiement progressif fournit une comparaison directe pour localiser la régression.

Comment enquêter

Désactivez le groupe concerné par le flag, comparez les deux chemins d’enregistrement et vérifiez les résultats persistés avant d’élargir à nouveau le déploiement.

Modification d’une dépendance

Une mise à niveau de package coïncide avec un nouveau comportement.

Type de problème : Dégradation des performances (pages, tâches ou API plus lentes, soudainement ou progressivement).

Requêtes ralenties après la mise à niveau de l’ORM

Statut : Ouvert

Description

Une mise à niveau de l’ORM modifie l’exécution d’une lecture courante, ce qui ralentit les requêtes sans changer la quantité de données demandée par les utilisateurs.

Ce qui s’est passé

Les enregistrements de requêtes lentes apparaissent avec le build mis à niveau et se concentrent autour d’une requête générée. La version précédente utilise une forme de requête différente pour la même entrée, tandis que le volume des requêtes reste comparable. La modification de la dépendance est une cause plausible du nouveau travail effectué par la base de données.

Comment enquêter

Comparez le SQL généré et les plans de requête entre les versions de l’ORM, examinez le changement de comportement de chargement et testez une requête corrigée ou un retour à la version précédente de la dépendance.

Ajout d’une gestion qui masque les erreurs

Un commit ajoute une gestion générique des erreurs sur un chemin important.

Type de problème : Échec silencieux (une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués).

Le contrôleur masque toutes les exceptions

Statut : Ouvert

Description

Un contrôleur convertit désormais les opérations échouées en réponses réussies, empêchant les appelants et la surveillance des erreurs de détecter que le travail n’a pas été effectué.

Ce qui s’est passé

Le contrôleur modifié enveloppe son opération principale dans un gestionnaire générique qui renvoie une réponse de réussite. Les traces des requêtes contiennent une exception avant la réponse, mais aucun résultat persistant correspondant. Le nouveau gestionnaire masque les échecs au lieu de les corriger, si bien que les utilisateurs peuvent perdre leurs modifications sans voir d’erreur.

Comment enquêter

Examinez la branche de gestion générique, préservez les réponses d’échec pour les opérations infructueuses et vérifiez que la réussite n’est renvoyée qu’une fois l’écriture terminée.

Effet d’une migration

Une migration de schéma modifie le comportement des requêtes.

Type de problème : Dégradation des performances (pages, tâches ou API plus lentes, soudainement ou progressivement).

Les requêtes sont 20 fois plus lentes après la migration

Statut : Ouvert

Description

Une migration de schéma supprime l’index utilisé par une requête fréquente, ce qui augmente son temps d’exécution et ralentit les requêtes qui en dépendent.

Ce qui s’est passé

La requête concernée prend 20 fois plus de temps après la migration. Son plan passe d’une recherche indexée à un balayage étendu, alors que la forme de la requête reste inchangée. L’absence d’index oblige chaque requête à examiner beaucoup plus de lignes et augmente le travail de la base de données sous un trafic normal.

Comment enquêter

Comparez la migration et les plans de requête, confirmez la structure d’index requise et rétablissez un index approprié en suivant la procédure de migration sécurisée de la base de données.

Performances

Hausse soudaine de la latence

Une augmentation brutale.

Type de problème : Régression (comportement dégradé par un déploiement ou une modification de configuration spécifique).

Le chargement de la page est passé à 1,2 s

Statut : Ouvert

Description

Le chargement des pages est devenu quatre fois plus lent immédiatement après un déploiement, ajoutant une attente visible à un parcours utilisateur qui aboutit par ailleurs.

Ce qui s’est passé

La durée de chargement des pages passe de 300 ms à 1,2 s après le déploiement. Les traces des requêtes montrent que l’augmentation se situe dans la phase de chargement des données côté serveur, et non dans le téléchargement des ressources. Les réponses aboutissent toujours ; le seul décompte des erreurs ne révèle donc pas cette dégradation de l’expérience.

Comment enquêter

Comparez le code de chargement des données et les temps des requêtes entre les déploiements, puis vérifiez le chemin lent avec la même entrée de requête.

Dérive progressive de la latence

Un ralentissement graduel sur plusieurs jours ou semaines, qui passe inaperçu.

Type de problème : Dégradation des performances (pages, tâches ou API plus lentes, soudainement ou progressivement).

La recherche ralentit chaque semaine

Statut : Ouvert

Description

La recherche ralentit peu à peu, accumulant un délai perceptible par les utilisateurs sans qu’un pic d’incident unique ne le révèle.

Ce qui s’est passé

Des recherches comparables prennent environ 5 % de plus chaque semaine. Cette dérive persiste même après prise en compte du volume des requêtes et se concentre dans la recherche des données plutôt que dans le transfert des réponses. L’augmentation du travail par requête est une cause possible, même si aucun déploiement isolé n’explique la tendance.

Comment enquêter

Comparez les plans de requête, le nombre de lignes examinées et la taille des index sur les périodes de référence. Vérifiez si la croissance des données a modifié le coût du chemin de recherche courant.

Latence de queue

Seules les requêtes les plus lentes se dégradent.

Type de problème : Dégradation des performances (pages, tâches ou API plus lentes, soudainement ou progressivement).

La latence p99 a triplé

Statut : Ouvert

Description

Les requêtes les plus lentes prennent beaucoup plus de temps, tandis que les requêtes habituelles restent rapides, masquant la dégradation de l’expérience pour un groupe plus restreint d’utilisateurs.

Ce qui s’est passé La latence p99 triple tandis que la médiane reste stable. Les traces lentes passent la majeure partie de ce temps supplémentaire à attendre une ressource partagée avant l’exécution. Les moyennes agrégées masquent ces attentes, mais les requêtes concernées restent bloquées assez longtemps pour risquer des délais d’expiration côté client.

Comment enquêter

Regroupez les traces lentes par ressource et par charge de travail, comparez leur temps d’attente à leur temps d’exécution et examinez la contention avant d’augmenter la capacité.

Apparition de requêtes lentes

Une nouvelle requête lente ou un nouveau schéma N+1.

Type de problème : Dégradation des performances (Pages, tâches ou API plus lentes, de façon soudaine ou progressive.)

Une page effectuant 400 requêtes

Statut : Ouvert

Description

Une page effectue une requête distincte dans la base de données pour chaque élément affiché, ce qui augmente le temps de réponse et la charge de la base de données à mesure que la liste s’allonge.

Ce qui s’est passé

Une requête de page exécute désormais 400 requêtes ayant la même forme d’instruction, mais des identifiants d’enregistrement différents. Ces lectures répétées ont lieu en série après la requête initiale de la liste. Ce schéma N+1 augmente le travail proportionnellement au nombre d’éléments affichés, au lieu de récupérer ensemble les données associées.

Comment enquêter

Suivez la requête par élément, regroupez les lectures associées ou utilisez une jointure, puis comparez le nombre de requêtes et le temps de réponse avec ceux d’une liste représentative.

Dérive du démarrage et du démarrage à froid

Les services mettent plus de temps à démarrer.

Type de problème : Risque de capacité (Signalant une limite avant qu’elle ne soit atteinte.)

Les déploiements mettent plus de temps à être opérationnels

Statut : Ouvert

Description

Les nouvelles instances mettent plus de temps à être prêtes, ce qui ralentit les déploiements et réduit la rapidité avec laquelle le service peut répondre à une demande supplémentaire.

Ce qui s’est passé

L’intervalle entre le démarrage du processus et son état opérationnel est trois fois supérieur à sa valeur de référence précédente. Les journaux de démarrage montrent que le délai supplémentaire survient avant la fin de l’initialisation, tandis que la latence des requêtes en régime stable reste similaire. Les déploiements progressifs et les montées en charge attendent donc plus longtemps avant de disposer d’une capacité utilisable.

Comment enquêter

Décomposez le démarrage en chargement des dépendances, initialisation et vérifications de disponibilité, comparez chaque phase à la version précédente et supprimez les tâches inutiles du parcours de vérification de disponibilité.

Augmentation du temps d’attente dans la file d’attente

Les tâches attendent plus longtemps avant de démarrer.

Type de problème : Échec d’une tâche en arrière-plan (Tâches planifiées manquées, dupliquées, bloquées ou vides.)

Les e-mails partent avec 20 minutes de retard

Statut : Ouvert

Description

Les tâches d’envoi d’e-mails attendent longtemps dans la file d’attente avant leur exécution, ce qui retarde les messages même si leur envoi aboutit toujours.

Ce qui s’est passé

Le délai entre le déclenchement d’un e-mail et la tentative d’envoi atteint 20 minutes. Une fois qu’un worker démarre une tâche, les temps de traitement et de réponse du fournisseur restent normaux. Le retard se situe avant l’exécution ; le seul décompte des envois réussis ne révèle donc pas que les messages arrivent en retard.

Comment enquêter

Comparez l’ancienneté des tâches dans la file d’attente, la concurrence des workers et les types de tâches concurrents. Supprimez le goulot d’étranglement ou séparez les e-mails urgents, tout en préservant un comportement de nouvelle tentative sûr.

Infrastructure

Approche d’une limite

Quotas cloud, crédits d’utilisation en rafale, limites de débit d’API, descripteurs de fichiers, limites de forfait.

Type de problème : Risque de capacité (Signalant une limite avant qu’elle ne soit atteinte.)

Épuisement des crédits d’utilisation en rafale

Statut : Ouvert

Description

Les crédits d’utilisation en rafale du système de fichiers sont consommés plus vite qu’ils ne se reconstituent, ce qui risque de provoquer une limitation du démarrage et d’autres tâches gourmandes en stockage.

Ce qui s’est passé

Le solde de crédits diminue au fil des intervalles successifs, car les lectures dépassent le niveau de référence provisionné. Le démarrage de nouvelles instances se superpose à ces lectures et dépend du débit disponible. Cette tendance indique que la capacité d’utilisation en rafale restante est limitée, mais ne prouve pas que le volume a déjà été soumis à une limitation.

Comment enquêter

Comparez le débit de stockage à son niveau de référence et au taux de reconstitution des crédits, identifiez les principaux lecteurs et ajustez le provisionnement ou les E/S au démarrage avant l’épuisement des crédits.

Saturation

CPU, mémoire, pools de connexions, pools de threads, disque.

Type de problème : Risque de capacité (Signalant une limite avant qu’elle ne soit atteinte.)

Pool de connexions presque saturé

Statut : Ouvert

Description

Le pool de connexions à la base de données dispose de peu de marge lors des pics de trafic, ce qui oblige les requêtes à attendre avant de pouvoir exécuter une requête SQL.

Ce qui s’est passé

L’utilisation du pool atteint 95 % lors des pics de charge et les attentes pour obtenir une connexion augmentent en parallèle. Le temps d’exécution des requêtes reste relativement stable une fois la connexion disponible. La contention se situe à la limite du pool et peut transformer des pics normaux de requêtes en délais d’expiration.

Comment enquêter

Examinez les connexions conservées trop longtemps et la durée des transactions, vérifiez la capacité de la base de données et corrigez la rétention inutile des connexions avant d’augmenter la limite du pool.

Augmentation du retard

Une file d’attente se remplit plus vite qu’elle ne se vide.

Type de problème : Échec d’une tâche en arrière-plan (Tâches planifiées manquées, dupliquées, bloquées ou vides.)

La file d’attente des tâches augmente depuis 6 heures

Statut : Ouvert

Description

Les nouvelles tâches arrivent plus vite qu’elles ne sont terminées, ce qui augmente régulièrement le volume de travail accepté en attente de traitement.

Ce qui s’est passé

La file d’attente des tâches augmente pendant six heures consécutives, car le nombre de tâches ajoutées reste supérieur au nombre de tâches terminées. Les tâches les plus anciennes continuent de vieillir même si les workers sont actifs. Le service traite une partie du travail, mais son débit ne suffit pas à absorber la charge entrante.

Comment enquêter

Comparez les taux d’arrivée et de traitement par type de tâche, identifiez les tâches lentes ou relancées et rétablissez une capacité de traitement suffisante pour résorber le retard le plus ancien.

Exécution planifiée manquée

Une tâche cron ne s’est pas exécutée, s’est exécutée deux fois ou a duré trop longtemps.

Type de problème : Échec d’une tâche en arrière-plan (Tâches planifiées manquées, dupliquées, bloquées ou vides.)

Export nocturne ignoré

Statut : Ouvert

Description

Un export planifié n’a pas démarré, privant les consommateurs en aval des données à jour normalement produites par cette exécution.

Ce qui s’est passé

Aucun enregistrement de démarrage ou de fin n’existe pour l’export nocturne du dimanche, alors que les exécutions planifiées voisines sont présentes. Aucun résultat n’est non plus disponible pour cet intervalle planifié. Cette lacune correspond à un déclenchement manqué ou à un échec d’admission, plutôt qu’à une tâche exécutée qui aurait renvoyé une erreur.

Comment enquêter

Vérifiez l’exécution du planificateur, la gestion des fuseaux horaires et les verrous empêchant les chevauchements, puis relancez l’intervalle manquant après avoir confirmé que la reprise ne dupliquera pas les exports.

Boucles de plantage

Redémarrages, arrêts pour manque de mémoire, vérifications de disponibilité en échec.

Type de problème : Échec d’une tâche en arrière-plan (Tâches planifiées manquées, dupliquées, bloquées ou vides.)

Le worker redémarre toutes les 12 minutes

Statut : Ouvert

Description

Un worker redémarre à plusieurs reprises avant de pouvoir assurer un traitement normal, interrompant les tâches en cours et retardant celles en attente.

Ce qui s’est passé

Le worker démarre, traite des tâches, puis s’arrête selon un cycle d’environ 12 minutes. Chaque redémarrage fait perdre l’état du processus en cours et entraîne la remise en file des tâches inachevées. Ce schéma indique des défaillances répétées du processus, mais le motif de l’arrêt doit permettre de distinguer un plantage d’un arrêt dû aux ressources ou d’un échec de vérification de disponibilité.

Comment enquêter

Examinez les codes de sortie, l’utilisation de la mémoire et les événements de vérification de disponibilité autour de chaque redémarrage. Corrigez la défaillance et vérifiez que les tâches interrompues reprennent sans effets secondaires en double.

Expiration imminente

Certificats, domaines, jetons d’API, autorisations OAuth.

Type de problème : Risque de capacité (Signalant une limite avant qu’elle ne soit atteinte.)

Certificat TLS sur le point d’expirer

Statut : Ouvert

Description

Un certificat utilisé dans le chemin de service actif approche de son expiration, sans preuve qu’un remplacement ait été installé.

Ce qui s’est passé

Le certificat TLS servi par le point de terminaison expire dans six jours. Les vérifications répétées renvoient toujours le même certificat ; le renouvellement n’a donc pas encore atteint la couche de service. Les connexions fonctionnent actuellement, mais leur validation échouera si ce certificat reste actif après la fin de sa période de validité.

Comment enquêter

Vérifiez l’automatisation du renouvellement et le déploiement du certificat, installez le remplacement et vérifiez le certificat effectivement servi aux clients.

Erreurs du fournisseur cloud

Limitation ou erreurs des API AWS ou GCP.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

S3 ralentit les téléversements

Statut : Ouvert

Description

Les téléversements d’objets passent plus de temps à relancer les requêtes auprès du fournisseur de stockage, ce qui ralentit les transferts des utilisateurs et mobilise les workers de téléversement.

Ce qui s’est passé

Les requêtes S3 renvoient des réponses SlowDown pendant les téléversements, suivies de tentatives répétées pour les mêmes objets. La durée supplémentaire est due aux nouvelles tentatives auprès du stockage, et non au traitement local des fichiers. Les réponses finales réussies peuvent masquer l’attente et l’utilisation de ressources supplémentaires sur le parcours de téléversement.

Comment enquêter

Examinez la concurrence des requêtes et le délai exponentiel entre les nouvelles tentatives, comparez les préfixes d’objets concernés et confirmez que les téléversements limités reprennent sans redémarrer le travail déjà terminé.

Services tiers

Interruption des webhooks

Les webhooks entrants attendus cessent d’arriver.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

Les webhooks de livraison des e-mails ont cessé

Statut : Ouvert

Description

Les envois d’e-mails se poursuivent, mais les rappels de livraison ont cessé, empêchant l’état de livraison local de refléter ce que le fournisseur a réellement fait.

Ce qui s’est passé

Aucun événement de livraison d’e-mail n’arrive pendant une heure, alors que les requêtes d’envoi sortantes reçoivent toujours des identifiants du fournisseur. L’interruption concerne les rappels, et non l’ensemble de l’activité liée aux e-mails. Des messages ont pu être livrés ou échouer sans que l’un ou l’autre de ces résultats ne parvienne à l’application.

Comment enquêter

Comparez les enregistrements de livraison du fournisseur aux réceptions locales de webhooks, vérifiez le point de terminaison de rappel et la validation de signature, puis rejouez les événements manquants en toute sécurité.

Dégradation du fournisseur

Erreurs ou latence d’un fournisseur dont vous dépendez.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

Codes de connexion jamais envoyés

Statut : Ouvert

Description

Les demandes de connexion semblaient aboutir alors que le fournisseur de messagerie rejetait les messages nécessaires aux utilisateurs pour terminer leur authentification.

Ce qui s’est passé

Les codes de connexion ne sont jamais arrivés, car le fournisseur de messagerie ne considérait plus le domaine d’envoi comme vérifié. L’envoi s’effectuait en arrière-plan ; l’API renvoyait donc toujours 200.

Comment enquêter

Rétablissez la vérification du domaine d’envoi et examinez les résultats des envois en arrière-plan. Signalez le rejet de la livraison des codes au lieu de considérer la réponse 200 de l’API comme une preuve de livraison.

Limitation du débit par le fournisseur

Vous êtes soumis à une limitation.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

Le quota de l’API de gestion des tickets était épuisé chaque jour

Statut : Ouvert

Description

Une collecte récurrente de tickets dépassait le quota du fournisseur et laissait la dernière région partiellement obsolète, tout en signalant une fin d’exécution normale.

Ce qui s’est passé

Une collecte quotidienne a atteint le quota de l’API de gestion des tickets chaque jour pendant deux semaines, avec environ 10,5k requêtes pour une limite de 10k. La dernière région n’a jamais été entièrement actualisée et la tâche s’est terminée normalement à chaque fois.

Comment enquêter

Répartissez les requêtes entre les régions, reprenez à partir de la partie incomplète après le rétablissement du quota et consignez toute exécution partielle lorsque la collecte s’arrête à la limite du fournisseur.

Modification du contrat

La structure de réponse d’un fournisseur change.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

Un champ du fournisseur arrive vide

Statut : Ouvert

Description

Une réponse du fournisseur ne fournit plus un champ requis par l’application, interrompant le traitement alors même que la requête en amont aboutit.

Ce qui s’est passé

Des valeurs auparavant renseignées arrivent vides dans des réponses réussies du fournisseur. L’application suppose toujours que le champ est présent et ne peut pas effectuer la mise à jour correspondante. Le changement se produit à la frontière de l’intégration sans échec HTTP ; la surveillance au niveau du transport reste donc saine.

Comment enquêter

Comparez la structure des réponses brutes au contrat attendu et aux changements du fournisseur, validez les champs obligatoires et gérez explicitement la valeur manquante avant de relancer les mises à jour.

Correspondance avec un incident fournisseur

La page d’état d’un fournisseur signale un incident qui coïncide avec vos erreurs.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

Les erreurs de connexion coïncident avec un incident chez un fournisseur

État : Ouvert

Description

Les échecs de connexion coïncident avec un incident chez un fournisseur d’identité, ce qui suggère un problème de dépendance en amont plutôt qu’une panne générale de l’application.

Ce qui s’est passé

Les erreurs de connexion commencent au même moment et dans la même région que ceux indiqués sur la page d’état du fournisseur d’identité. Les échecs surviennent lors de l’échange avec le fournisseur, tandis que les requêtes sans rapport avec celui-ci continuent de fonctionner. La chronologie et la dépendance concernée étayent cette corrélation, sans toutefois exclure une défaillance locale supplémentaire.

Comment enquêter

Comparez les échanges en échec avec le périmètre de l’incident du fournisseur, vérifiez la configuration locale et surveillez le rétablissement tout en proposant aux utilisateurs une procédure claire pour réessayer.

Dérive du comportement du LLM

Les sorties du modèle changent : longueur, refus, JSON mal formé, utilisation des jetons.

Type de problème : Défaillance d’une dépendance (Un fournisseur ou un service en amont est en panne ou a changé.)

Échec de la sortie structurée dans 4 % des cas

État : Ouvert

Description

Les réponses du modèle respectent moins souvent le contrat de sortie structurée, ce qui empêche les tâches en aval d’utiliser des complétions pourtant réussies.

Ce qui s’est passé

Les échecs d’analyse de la sortie structurée passent de 0,1 % à 4 % pour la même fonctionnalité. Les réponses non valides comportent des champs manquants ou du texte qui ne respecte pas la structure JSON attendue. Les requêtes au fournisseur aboutissent toujours, mais l’application ne peut pas utiliser ces résultats en toute sécurité et doit rejeter ou réessayer les tâches concernées.

Comment enquêter

Comparez la version du modèle, les prompts et la validation du schéma avant et après le changement, examinez les sorties non valides et vérifiez une correction imposant un format contraint avant de rétablir le traitement normal.

Intégrité des données

Écriture non persistée

Une sauvegarde est confirmée, mais les données n’apparaissent jamais par la suite.

Type de problème : Défaillance silencieuse (Une fonctionnalité semble fonctionner, mais ne fonctionne pas : actions sans effet, exceptions ignorées, exécution partielle, résultats incorrects, états bloqués.)

La synchronisation CI n’a rien enregistré, mais a signalé une réussite

État : Ouvert

Description

Une synchronisation CI a signalé une réussite après avoir récupéré des pipelines, mais n’en a enregistré aucun, donnant l’impression que les données du projet étaient actualisées.

Ce qui s’est passé

Une synchronisation CI a duré 30 minutes, récupéré des milliers de pipelines, n’en a enregistré aucun et s’est déclarée réussie. Les erreurs par projet ont été ignorées, si bien que l’historique de synchronisation semblait sain alors que les données devenaient obsolètes.

Comment enquêter

Examinez les erreurs par projet qui ont été ignorées, rapprochez les pipelines récupérés des lignes persistées et ne relancez que les projets concernés après avoir vérifié les écritures.

Traitement en double

Le même événement, travail ou paiement est traité deux fois.

Type de problème : Intégrité des données (Écritures perdues, doublons, corruption, enregistrements incohérents.)

Deux e-mails de bienvenue par inscription

État : Ouvert

Description

Chaque nouveau compte reçoit deux e-mails de bienvenue, car le même événement d’inscription peut déclencher l’envoi plusieurs fois.

Ce qui s’est passé

Deux tentatives d’envoi terminées partagent le même ID d’événement d’inscription et le même destinataire, mais utilisent des ID de livraison différents. Un événement réessayé entre de nouveau dans le gestionnaire des e-mails de bienvenue sans garde de livraison enregistrée. L’effet secondaire en double atteint l’utilisateur, même si les deux tentatives réussissent individuellement.

Comment enquêter

Suivez la nouvelle livraison de l’événement et la garde d’envoi, rendez la livraison idempotente pour chaque événement d’inscription et vérifiez qu’une relecture ne produit qu’un seul e-mail.

Écart de rapprochement

Les décomptes diffèrent d’un système à l’autre.

Type de problème : Intégrité des données (Écritures perdues, doublons, corruption, enregistrements incohérents.)

Dépôt versé, mais jamais crédité

État : Ouvert

Description

Le versement ultérieur d’un dépôt n’a pas mis à jour le portefeuille de l’utilisateur, alors que le fournisseur avait précédemment signalé l’échec de ce dépôt.

Ce qui s’est passé

Un fournisseur de paiement a signalé l’échec d’un dépôt, puis l’a versé 40 minutes plus tard. L’argent est arrivé, mais le portefeuille de l’utilisateur n’a jamais été crédité et aucune erreur n’a été signalée.

Comment enquêter

Comparez l’état final du dépôt chez le fournisseur avec le registre du portefeuille. Rapprochez le crédit manquant et vérifiez que les changements d’état ultérieurs sont traités sans crédit en double.

Dérive des indicateurs métier

Les inscriptions, candidatures, paiements ou messages s’écartent fortement de leur plage habituelle.

Type de problème : Dysfonctionnement du flux métier (Baisse d’un indicateur clé due à une cause technique.)

Baisse de 35 % des candidatures

État : Ouvert

Description

Le nombre de candidatures terminées est inférieur au niveau habituel malgré un trafic comparable vers le formulaire, ce qui indique un problème dans le flux de soumission.

Ce qui s’est passé

Le nombre de candidatures a baissé de 35 % par rapport à la même heure la semaine dernière, tandis que les visites du formulaire restent comparables. L’écart apparaît entre les tentatives de soumission et les candidatures enregistrées. Ce schéma suggère un problème de traitement ou de validation plutôt qu’une simple baisse de la demande.

Comment enquêter

Comparez les résultats de soumission et les motifs de validation avec la période de référence, puis suivez les tentatives concernées jusqu’à leur persistance avant d’attribuer la baisse au comportement des utilisateurs.

Sortie vide

Les tâches signalent une réussite, mais ne produisent rien.

Type de problème : Défaillance d’une tâche en arrière-plan (Travail planifié manqué, dupliqué, bloqué ou sans résultat.)

Le nettoyage de rétention n’a rien expurgé

État : Ouvert

Description

Une tâche de nettoyage de la rétention continuait de s’exécuter sans expurger les données de prompt qu’elle avait identifiées pour les organisations ayant désactivé la rétention.

Ce qui s’est passé

Pour les organisations ayant désactivé la rétention des prompts, une tâche de nettoyage continuait de trouver des données à expurger, n’expurgeait aucune ligne et passait à la suite. Elle s’est exécutée comme prévu, sans exception, pendant un mois dans 11 organisations.

Comment enquêter

Comparez la sélection des éléments candidats avec le prédicat d’expurgation et le nombre de lignes affectées. Vérifiez que les données admissibles sont supprimées avant de relancer le nettoyage concerné.

Données obsolètes

Les caches et les tâches de synchronisation cessent de s’actualiser.

Type de problème : Intégrité des données (Écritures perdues, doublons, corruption, enregistrements incohérents.)

Données de l’annuaire obsolètes depuis trois jours

État : Ouvert

Description

Les lectures de l’annuaire renvoient un ancien instantané alors que la source en amont a changé, laissant aux utilisateurs des enregistrements obsolètes.

Ce qui s’est passé

La dernière actualisation réussie de l’annuaire remonte à trois jours. Les lectures continuent de renvoyer cet instantané, tandis que les tentatives de synchronisation ne mettent pas à jour son marqueur de fraîcheur. Les contrôles de disponibilité restent au vert, car le cache répond toujours, mais les entrées récemment ajoutées ou modifiées sont absentes.

Comment enquêter

Suivez la tâche d’actualisation et la mise à jour du point de contrôle, comparez les enregistrements source à l’instantané en cache et vérifiez la fraîcheur après une resynchronisation sans risque.

Coût

Pic de volume des journaux

Un déploiement génère soudainement beaucoup trop de journaux.

Type de problème : Anomalie de coût (Les dépenses liées aux journaux, au cloud ou à l’utilisation des LLM augmentent fortement.)

Une ligne de débogage est journalisée 40 millions de fois par jour

État : Ouvert

Description

Un message de débogage devenu fréquent domine le flux de journaux, augmentant l’ingestion et le stockage sans hausse correspondante du trafic.

Ce qui s’est passé

Après un déploiement, une ligne de débogage génère 40 millions d’événements de journal par jour. Son point d’appel se trouve dans une opération répétée, si bien que chaque requête en émet désormais de nombreuses copies. Cette hausse de volume est due au comportement de journalisation, et non à une augmentation comparable de l’activité utile de l’application.

Comment enquêter

Localisez l’appel de journalisation répété, réduisez ou échantillonnez les sorties redondantes et confirmez que la couverture diagnostique reste utile une fois le volume revenu à son niveau de référence.

Anomalie des dépenses cloud

Les dépenses augmentent pour un service ou une ressource.

Type de problème : Anomalie de coût (Les dépenses liées aux journaux, au cloud ou à l’utilisation des LLM augmentent fortement.)

Les coûts de transfert de données ont doublé

État : Ouvert

Description

Les dépenses de transfert de données ont doublé sans hausse comparable du trafic, ce qui suggère que les requêtes empruntent un chemin plus coûteux.

Ce qui s’est passé

Les coûts de transfert doublent du jour au lendemain, alors que le nombre de requêtes de l’application reste similaire. L’augmentation concerne principalement le trafic entre les services, plutôt que la taille des réponses destinées aux utilisateurs. Un changement de routage ou de placement peut entraîner des transferts répétés ou interrégionaux que les métriques habituelles des requêtes ne révèlent pas.

Comment enquêter

Ventilez l’utilisation du transfert par source, destination et changement de déploiement, puis vérifiez si le routage ou des récupérations en double expliquent les octets supplémentaires.

Pic des dépenses liées aux LLM

L’utilisation des jetons augmente selon la fonctionnalité ou le client.

Type de problème : Anomalie de coût (Les dépenses liées aux journaux, au cloud ou à l’utilisation des LLM augmentent fortement.)

Une boucle d’agent a consommé le budget d’une semaine

État : Ouvert

Description

Un agent émet à plusieurs reprises des appels similaires au modèle sans terminer sa tâche, concentrant une utilisation inhabituellement élevée de jetons dans un seul flux de travail.

Ce qui s’est passé

L’exécution de l’agent d’un compte consomme en une journée le budget hebdomadaire habituel de jetons. Les appels consécutifs répètent le même résultat d’outil et transmettent un contexte de plus en plus long, sans qu’aucun résultat final de la tâche n’apparaisse. Cette boucle répétée augmente les coûts sans produire de progrès utile supplémentaire.

Comment enquêter

Examinez la décision et le résultat d’outil répétés, arrêtez l’exécution improductive et ajoutez des tentatives limitées ainsi qu’une sortie en cas d’absence de progrès avant de relancer la tâche.

Lacunes de télémétrie

Silence du service

Une source cesse d’envoyer des journaux.

Type de problème : Lacune d’observabilité (Zones où vous êtes dans l’angle mort, ou télémétrie qui crée un risque.)

La flotte de workers est devenue silencieuse

État : Ouvert

Description

Une flotte de workers a cessé d’émettre des journaux après un changement de configuration, supprimant les traces de diagnostic nécessaires pour comprendre son activité en cours.

Ce qui s’est passé

Le volume de journaux des workers tombe à zéro alors que l’activité de la file d’attente montre que les tâches continuent d’être traitées. Le silence commence avec le changement de configuration et touche toute la flotte, pas un seul hôte. Cela indique un problème dans le chemin de journalisation ou de livraison, mais ne prouve pas que tous les workers se sont arrêtés.

Comment enquêter

Comparez la configuration du logger et de l’exportateur avec la version précédente, examinez les erreurs de livraison et vérifiez qu’un événement connu d’un worker est bien transmis de son émission à son ingestion.

Format illisible

Un nouveau format de journal ne peut pas être analysé.

Type de problème : Lacune d’observabilité (Zones où vous êtes dans l’angle mort, ou télémétrie qui crée un risque.)

Nouveau format de journal illisible

État : Ouvert

Description

Une mise à niveau du logger a modifié le format des enregistrements, entraînant la perte des champs structurés utilisés pour l’analyse et la corrélation dans les journaux entrants.

Ce qui s’est passé

La source continue d’envoyer des enregistrements, mais les échecs d’analyse commencent avec la mise à niveau du logger. Les lignes brutes contiennent une nouvelle enveloppe autour des champs que l’analyseur attend au niveau supérieur. Les événements arrivent sans niveau de gravité, message ni contexte de requête fiables, ce qui réduit leur valeur diagnostique.

Comment enquêter

Comparez les anciens et les nouveaux enregistrements bruts, mettez à jour le contrat d’analyse et vérifiez des événements représentatifs, notamment multilignes et d’erreur, avant de considérer la source comme saine.

Angle mort

Une route ou une tâche importante ne dispose d’aucune télémétrie.

Type de problème : Lacune d’observabilité (Zones où vous êtes dans l’angle mort, ou télémétrie qui crée un risque.)

Aucun journal sur le point de terminaison des paiements

État : Ouvert

Description

Un nouveau point de terminaison de paiement traite les requêtes sans produire de télémétrie applicative, ce qui complique l’analyse des échecs et des opérations incomplètes.

Ce qui s’est passé

Les enregistrements d’entrée montrent que les requêtes atteignent le point de terminaison, mais aucun événement de démarrage, résultat ou ID de requête correspondant n’apparaît dans le flux de journaux. Les autres routes de paiement continuent d’émettre ces événements. L’absence de couverture empêche de suivre une requête à travers la validation, les appels au fournisseur et la persistance.

Comment enquêter

Suivez le middleware de journalisation de la route, ajoutez des événements de résultat structurés avec des ID de corrélation et vérifiez les traces sans enregistrer d’identifiants de paiement ni de données sensibles.

Décalage d’horloge

Les horodatages divergent entre les sources.

Type de problème : Lacune d’observabilité (Zones où vous êtes dans l’angle mort, ou télémétrie qui crée un risque.)

Hôte en retard de 4 minutes

État : Ouvert

Description

Un hôte horodate les événements plus tôt que ses pairs, ce qui donne l’impression qu’une même requête s’exécute dans le désordre d’un service à l’autre.

Ce qui s’est passé

Les événements de l’hôte ont quatre minutes de retard par rapport aux mêmes ID de requête provenant d’autres sources. Les heures d’ingestion restent proches, l’écart vient donc de l’heure enregistrée pour l’événement et non d’un délai de transport. Ce décalage fausse les chronologies et peut induire en erreur les analyses de latence ou de séquence.

Comment enquêter

Vérifiez la synchronisation de l’heure de l’hôte et la sérialisation des horodatages, corrigez l’horloge, puis comparez à nouveau les événements corrélés avant de vous fier aux mesures temporelles entre services.

Exemples tirés du catalogue de détection Sazabi. Certains signaux sont encore en préparation.

Compatible avec votre stack

Parcourir toutes les intégrations

Fournisseurs de chat (3 intégrations)

• Slack
• Microsoft Teams
• Discord

Fournisseurs Git (2 intégrations)

• GitHub
• Bitbucket

Suivi des problèmes et astreintes (6 intégrations)

• Linear
• Atlassian
• PagerDuty
• incident.io
• Rootly
• VictorOps

Sources de logs (73 intégrations)

• AWS
• Vercel
• Supabase
• Cloudflare
• OpenTelemetry
• Fluent Bit
• GitHub
• Linear
• Webhooks
• Cursor
• GitHub Copilot
• Factory Droid
• OpenHands
• OpenClaw
• Hermes Agent
• Claude Agent SDK
• Google Cloud
• Railway
• Render
• Fly.io
• Netlify
• DigitalOcean
• Porter
• Modal
• Northflank
• Neon
• Convex
• Inngest
• Trigger.dev
• Temporal
• Mastra
• LangChain
• E2B
• Daytona
• OpenRouter
• Datadog
• Sentry
• PostHog
• Prometheus
• Elastic Cloud
• SigNoz
• Vector
• Respan
• New Relic
• evlog
• Plain
• Shopify
• Okta
• Auth0
• WorkOS
• SentinelOne
• Palo Alto Networks
• Zscaler
• HashiCorp Vault
• Jamf Pro
• osquery
• Linux auditd
• Stripe
• Claude Code
• Codex
• Devin
• Doppler
• Gemini
• Grafana Alloy
• oh-my-pi
• Sazabi Browser SDK
• Tailscale
• Unkey
• Jenkins
• Buildkite
• RunsOn
• WarpBuild
• Sazabi React Native SDK

Outils d’infrastructure (17 intégrations)

• AWS
• Google Cloud
• Vercel
• Cloudflare
• Kubernetes
• Terraform
• Railway
• Render
• Fly.io
• Netlify
• DigitalOcean
• Porter
• Argo CD
• Azure
• Heroku
• RunPod
• Tailscale

Outils de base de données (12 intégrations)

• Supabase
• Neon
• Postgres
• MySQL
• Redis
• ClickHouse
• Convex
• PlanetScale
• Airbyte
• Aiven
• MongoDB Atlas
• MongoDB Shell

Outils d’IA et de workflow (32 intégrations)

• Codex
• Cursor
• Gemini
• OpenCode
• Temporal
• Inngest
• Claude Agent
• Warp Oz
• Capy
• Tembo
• Hoplite
• Replicas
• Composio
• Exa
• The Context Company
• RentAHuman
• Cekura
• Langfuse
• Braintrust
• Respan
• Tines
• DeepWiki
• Context.dev
• AgentCat
• CodeRabbit
• Dagster
• DBOS Cloud
• Deepsec
• Devin
• ElevenLabs
• LangSmith
• Rivet

Outils d’équipe et d’exploitation (43 intégrations)

• Notion
• Google Drive
• Grafana
• Attio
• 1Password
• Intercom
• Axiom
• Honeycomb
• Better Stack
• Pydantic Logfire
• down.guide
• Pylon
• Clay
• Calendly
• Circleback
• Granola
• Happenstance
• Superhuman
• Mercury
• X
• Wiz
• Vanta
• Drata
• Semgrep
• Socket
• GitGuardian
• Google Security Operations
• VirusTotal
• Have I Been Pwned
• cve.now
• Clerk
• Resend
• Autumn
• Arize
• Checkly
• DoorDash
• Graphite
• GrowthBook
• Herd
• Mobbin
• Secureframe
• Stream
• Twilio

Études de cas

Lire les études de cas

Weave

Comment Weave récupère plus de 20 heures d’ingénierie par semaine en remplaçant la détection manuelle par Sazabi

Sazabi a transformé des angles morts en problèmes que nous détectons et corrigeons avant même que les clients ne les remarquent. Après la prévention complète d’un problème, le mieux est d’en être informé immédiatement, et c’est exactement ce que Sazabi nous apporte.

Andrew Churchill, cofondateur et CTO de Weave

• 8.5 min : délai pour trouver la cause racine d’un problème en production
• 9 min : temps de configuration

Lire l’étude de cas

Mastra

Comment Mastra remplace les enquêtes de 45 minutes par des alertes de cause racine de Sazabi

Sazabi nous a donné la visibilité sur la production dont nous avions besoin pour le lancement, sans avoir à mettre en place notre configuration d’observabilité habituelle. C’est désormais un filet de sécurité auquel nous faisons confiance à chaque déploiement.

Abhi Aiyer, cofondateur et CTO de Mastra

• 45 min : durée d’une enquête manuelle avant Sazabi
• 150 problèmes : problèmes de production identifiés en deux semaines

Lire l’étude de cas

XMTP Labs

Comment XMTP Labs a réduit le délai de détection des bugs de plusieurs jours à quelques minutes avec Sazabi

Avec Sazabi dans notre stack d’observabilité, nous trouvons les causes racines bien plus rapidement qu’avec toutes nos approches précédentes.

Nick Molnar, CTO de XMTP Labs

• 5 min : délai pour signaler un incident majeur
• 20 min : délai pour déployer un correctif pour un problème critique

Lire l’étude de cas

Depuis notre blog

• Présentation de Sazabi BYOC : exécutez Sazabi dans votre propre cloud : Avec Sazabi BYOC, la partie de Sazabi qui reçoit, traite et stocke vos logs s’exécute dans votre propre compte cloud, et Sazabi en assure l’exploitation.
• Présentation de cve.now : un flux gratuit de vulnérabilités de sécurité pour les agents : cve.now est un flux gratuit de CVE et d’avis de sécurité destiné aux agents et aux équipes qui les utilisent. Aucun identifiant, inscription ou clé API n’est nécessaire.
• Annonce de Sazabi 1.0 et de sa disponibilité générale : Sazabi 1.0 est désormais disponible, avec deux nouvelles fonctionnalités — Dashboards et Log Search — et une inscription entièrement autonome en moins de dix minutes.

Voir tous les articles

Une approche différente de l’observabilité et de la sécurité

01 Tout est un log

Métriques, traces, événements d’application, actions d’agents. Tout décrit ce qui s’est passé. Les logs offrent aux humains et aux agents une base commune pour comprendre un système.

02 Les logs alimentent la détection des anomalies

Vous ne devriez pas avoir à prévoir chaque panne pour la détecter. Une base de logs permet à Sazabi de repérer les changements de comportement de votre système et d’enquêter sur ce qui s’est passé.

03 Conçu pour un monde natif de l’IA

L’IA transforme la façon dont les logiciels sont conçus et exploités. Sazabi donne aux humains et aux agents un accès partagé aux éléments de preuve et aux outils dont ils ont besoin pour agir.

Ce que disent nos clients

Au cours de nos deux premiers jours, Sazabi a détecté environ 8 problèmes que nous n’aurions pas trouvés autrement, même avec Sentry.

Bence R., Hoplite

Vivre dans le futur : Sazabi ouvre la PR, Cursor évalue les risques et l’approuve, et la CI est entièrement au vert.

Evan, AGREE

Toutes les alertes ne sont pas prioritaires, mais chacune permet d’agir. Je suis très impressionné par leur qualité.

Yash N., Sandstone

Certaines alertes de Sazabi me font dire 🤯, et c’est très utile. C’est d’autant plus important que nos microservices se multiplient.

Nanda G., Taiga

Les alertes Slack sont si bonnes que je n’ai pas eu besoin d’ouvrir le tableau de bord. Un agent de programmation corrige les bugs au fur et à mesure.

Charlie L., Autumn

Sazabi est la colonne vertébrale de notre astreinte. Et avec les nouvelles alertes de sécurité, nous pouvons paniquer en temps réel.

Ed P., WAJO

Prêt pour les entreprises

Utilisez votre propre cloud

Exécutez l’ingestion, le traitement et le stockage des logs dans votre propre compte AWS. Sazabi exploite le déploiement.

• Un stockage détenu par votre organisation
• Votre politique de conservation
• Un accès que vous pouvez révoquer

Lire l’annonce de BYOC

Conformité

Des normes de sécurité et des engagements en matière de confidentialité pour accompagner l’évaluation de votre équipe.

• SOC 2
• SOC 1
• ISO 27017
• ISO 27001
• GDPR

Visiter le centre de confiance

Accès et sécurité

Connectez votre fournisseur d’identité et contrôlez les accès dans toute votre organisation.

• SSO avec SAML / OIDC
• Provisionnement SCIM
• Autorisations basées sur les rôles
• Accès restreint aux projets
• Authentification à deux facteurs

Découvrir les contrôles d’accès

FAQ

Qu’est-ce que Sazabi ?

Sazabi est une plateforme d’observabilité et de sécurité native de l’IA destinée aux équipes d’ingénierie et aux agents de programmation. Elle analyse vos logs de production en parallèle de votre code, détecte les problèmes importants, enquête sur chacun d’eux jusqu’à en trouver la cause racine, puis transmet le résultat aux outils que votre équipe utilise déjà.

Dois-je écrire des moniteurs ou des règles d’alerte ?

Non. Sazabi surveille vos logs pour repérer les changements qui méritent un examen plus approfondi, par exemple un événement qui cesse de se produire, une étape qui commence à échouer silencieusement ou une latence qui augmente après un déploiement. Son agent enquête sur ces signaux, confirme qu’ils ont un impact réel, puis ouvre un problème, sans moniteurs, seuils ni règles d’alerte à maintenir.

À quels journaux et outils Sazabi se connecte-t-il ?

Envoyez des journaux provenant de sources comme Datadog, PostHog, Sentry, Google Cloud, Supabase et Cloudflare, et connectez votre code depuis GitHub pour que Sazabi puisse remonter des problèmes jusqu’au commit et au fichier concernés. Les problèmes sont transmis à votre équipe sur Slack, Microsoft Teams, par e-mail ou par SMS.

Comment Sazabi fonctionne-t-il avec les agents de programmation ?

Chaque problème est accompagné de sa cause racine et d’un plan de correction que vous pouvez transmettre directement à un agent de programmation comme Claude Code, Codex ou Cursor. Les agents peuvent également interroger Sazabi sur vos journaux via la CLI et MCP pendant qu’ils travaillent.

Mes journaux peuvent-ils rester dans mon propre cloud ?

Oui. Avec Sazabi BYOC, la réception, le traitement et le stockage des journaux s’effectuent dans votre propre compte AWS, et vos journaux restent dans un espace de stockage appartenant à votre organisation, tandis que Sazabi gère le déploiement. Les résultats des requêtes et les extraits de journaux peuvent toutefois être transmis à Sazabi et aux fournisseurs de modèles.

Combien coûte Sazabi ?

Hobby coûte $50, Startup $200 et Growth $1,000 par cycle de 30 jours, avec une utilisation incluse pour chaque offre. Enterprise propose des tarifs et des conditions personnalisés. Consultez la page des tarifs pour connaître le contenu de chaque offre.

Comment démarrer ?

Exécutez npx @sazabi/cli start dans votre terminal pour configurer Sazabi, ou suivez le guide de démarrage rapide dans la documentation.

URL canonique

https://www.sazabi.com