Historique des pannes de Unico

1. 30 août 2026 à 02:35 UTCinvestigating

   Cher client, Vers 23h00 (BRT) le vendredi 29 août 2026, nous avons identifié une instabilité affectant la création de processus à IDCloud. Pendant cette période, certaines demandes peuvent échouer ou connaître des délais de réponse plus lents que d'habitude. Nous reconnaissons les inconvénients que cela peut causer et apprécions votre compréhension. Une nouvelle mise à jour sera fournie sous peu. Équipe Unico

2. 30 août 2026 à 02:49 UTCidentified

   Notre équipe d'ingénierie a cartographié l'origine de l'instabilité affectant la création de processus dans IDCloud. L'équipe technique a déjà commencé à appliquer des mesures correctives, y compris l'augmentation des ressources dans la couche touchée et le suivi continu des principaux indicateurs. La restauration du service est gérée avec la priorité absolue et la mobilisation complète de l'ingénierie. Nous réaffirmons que d'autres mises à jour seront envoyées sous peu. Équipe Unico

3. 30 août 2026 à 02:57 UTCmonitoring

   Cher client, Notre équipe d'ingénierie a effectué les actions correctives nécessaires pour résoudre l'instabilité affectant la création de processus dans IDCloud. L'environnement est revenu à la stabilité, avec des indicateurs de disponibilité et de temps de réponse rétablis à des niveaux d'exploitation normaux à 11:48 PM (BRT). Le service est disponible pour une utilisation normale. À l'heure actuelle, notre équipe technique reste sous surveillance assistée, surveillant de près l'environnement pour assurer une performance cohérente et agir immédiatement en cas de fluctuation. Nous vous remercions de votre compréhension et réaffirmons que d'autres mises à jour seront envoyées sous peu. Équipe Unico

4. 30 août 2026 à 03:15 UTCresolved

   Cher client, Résumé et impact Entre 23h00 et 23h48 (BRT) le 29 août 2026, une panne a affecté la création de processus à IDCloud. Pendant cette fenêtre, certains clients utilisant ces flux ont connu des défaillances et des temps de réponse accrus, avec la propagation à des trajets dépendants, y compris l'authentification, la capture de documents, et la livraison de notification. Il n'y a eu aucun compromis sur l'intégrité ou la sécurité des renseignements traités, et aucune donnée n'a été perdue. Les indicateurs sont revenus à des niveaux d'exploitation normaux à 11:48 PM (BRT), avec une normalisation confirmée à la fois dans notre surveillance et du côté client, couvrant la création et l'achèvement du processus. Cause fondamentale et résolution L'origine a été identifiée dans notre couche de données: une routine de maintenance interne est devenue bloquée, et les opérations d'application ont commencé à faire la queue derrière jusqu'à ce que la limite de connexion disponible soit épuisée, réduisant la capacité de traitement. Notre équipe d'ingénieurs a mis fin à la routine bloquée, libérant immédiatement la file d'attente. Les connexions et la capacité de traitement ont été entièrement rétablies, sans changement de données. Engagement et prochaines étapes Notre équipe d'ingénierie se concentrera sur trois fronts: limiter les temps d'attente pour les routines de maintenance interne, empêcher les routines simultanées de fonctionner contre la même structure, et renforcer la résilience du service aux fluctuations de la couche de données. Un postmortem détaillé, comprenant le calendrier complet et un plan d'action assorti de délais, sera communiqué sous peu. Nous nous excusons sincèrement de l'impact sur vos opérations et restons disponibles par nos canaux de soutien. Équipe Unico

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 août 2026 à 20:26 UTCidentified

   Cher client, Nous avons détecté un impact sur certaines demandes IDCloud, affectant la capacité d'alerte comportementale (IDTrust) et le flux 1:N. Cette instabilité peut également affecter les clients du Mexique qui utilisent cette capacité. Notre équipe d'ingénieurs est mobilisée pour résoudre le problème dès que possible. Nous fournirons sous peu de nouvelles mises à jour.

2. 10 août 2026 à 20:29 UTCmonitoring

   Notre équipe d'ingénierie a identifié et mis en œuvre les actions nécessaires pour résoudre l'instabilité des capacités de flux IDCloud affectées. À l'heure actuelle, l'équipe technique effectue une analyse détaillée de notre couche de données et continue de surveiller l'environnement. Nous réaffirmons que d'autres mises à jour seront envoyées sous peu.

3. 10 août 2026 à 21:01 UTCresolved

   Résumé et impact Vers 17h08, une alerte automatisée a détecté une baisse de disponibilité dans le service de reconnaissance faciale (1:N flow), déclenchant l'incident. Le problème s'est rapidement aggravé et a commencé à affecter le service d'alerte de comportement et, par la suite, le flux de création de processus, en raison des décalages entre ces services. L'impact a touché un sous-ensemble de clients utilisant ces capacités. La situation s'est stabilisée à 17 h 22, les mesures revenant à des niveaux normaux. Cause fondamentale et résolution La cause principale était un pic de trafic généré par une charge de travail interne, qui a envoyé un volume élevé de demandes de reconnaissance faciale directement dans le pipeline biométrique, contournant la couche de bord utilisée par le trafic normal des clients. Ce volume supplémentaire a saturé la capacité de la base de données appuyant le service de reconnaissance faciale. La saturation a causé des délais dans ce service, qui a cadré au service d'orchestration biométrique du moteur, puis au service d'alerte comportementale, et enfin au flux de création de processus en utilisant ces capacités. Pour résoudre le problème, l'équipe a arrêté la charge de travail responsable de la crise et a augmenté la capacité de la base de données touchée. Ces actions ont atténué le problème, le volume d'erreurs revenant à des niveaux proches de zéro. Engagement et prochaines étapes Un élément de suivi a été ouvert afin de limiter le taux de charge de travail interne qui a causé l'augmentation, à titre de mesure préventive contre la récurrence. L'augmentation des capacités de la base de données touchée a déjà été réalisée au cours de l'incident lui-même.

4. 25 août 2026 à 13:05 UTCpostmortem

   ** Résumé** Le 10 août 2026, entre 17h08 et 17h27 \(Brassilia time\), l'indicateur de disponibilité du flux de reconnaissance faciale 1:N est tombé en dessous de 95%, avec un impact total d'environ 19 minutes. L'incident a été causé par la saturation de la base de données de recherche vectorielle utilisée par le moteur biométrique, résultant d'un comportement inattendu dans le mécanisme de consommation de queue, qui a généré un volume d'appel 2,36 fois plus élevé que configuré. La charge excédentaire a atteint la limite d'échelle maximale de la base de données, ce qui a entraîné des délais en cascade pour plusieurs services dépendants et affecté 55 clients ayant des erreurs pendant la période. **Impact** Les utilisateurs de la reconnaissance faciale, de l'authentification et de la création de processus proviennent de plusieurs clients qui ont connu des erreurs et des délais pendant la période. La saturation de la base de données est passée en cascade par les services d'orchestration biométrique, de moteur et de création de processus. L'atténuation a été réalisée en désactivant un service interne et en augmentant la limite maximale d'échelle de la base de données, stabilisant le service à 17 h 27. ** Cause de la mort** La cause principale était une combinaison de facteurs liés au comportement des services et à la capacité de l'infrastructure en cause. Le service a été configuré avec une limite de 2 requêtes par seconde, mais le mécanisme de consommation de la file d'attente s'est comporté de manière inattendue : les messages dont le traitement a dépassé le délai de reconnaissance ont été retransmis par la file d'attente sans annuler l'exécution originale — transformant 938 éléments de travail en 2 217 appels effectifs \(~8.4 RPS\). Ce trafic amplifié a atteint la base de données sans passer par la couche de protection des bords, qui limiterait normalement le volume de requête, puisque le chemin réseau utilisé dans ce flux n'a pas traversé ces contrôles. La base de données, qui fonctionnait déjà près de sa limite maximale, n'a pas pu absorber la charge supplémentaire — son CPU a atteint 88% tout en augmentant jusqu'au plafond configuré de 100 nœuds — et la latence de la requête a sauté de ~3 secondes à ~18,75 secondes à la p90, propagant des timeouts sur toute la chaîne de services dépendants. **Résolution** L'équipe a identifié le processus en question comme étant la source de la charge dans les quelques minutes suivant l'alerte. Le processus a été désactivé et la limite d'échelle maximale de la base de données a été portée de 100 à 150 nœuds. Avec ces deux actions, le service s'est stabilisé à 17h27. **Leçons apprises** L'incident a montré que la limitation du taux appliquée uniquement du côté de l'édition de messages est insuffisante lorsque le consommateur peut amplifier le volume par un renouvellement. Les contrôles des taux et de la convergence doivent également exister du côté de la consommation. De plus, les services internes qui accèdent aux composants essentiels par des voies qui contournent les protections de bord représentent un risque structurel — tout client interne peut générer une charge incontrôlée sur l'infrastructure partagée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 juillet 2026 à 12:42 UTCinvestigating

   Prezados clients, Identificamos uma instabilidade técnica pontual que afeta a atualização do painel de acompanhamento após o envio de documentos. Reforçamos que o fluxo de envio e assinatura está funcionando normalmente: os destinatários continuam recebendo e conseguindo assinar os arquivos. Pas d'entanto, o registro do envio pode temporariamente não ser exibido na lista de acompanhamento do remetente. Nossa equipe de engenharia já está atuando para corriger a exibição na interface e restabeleer o histórico no painel o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos informados sobre o progresso. Atenciosamente,

2. 31 juillet 2026 à 13:08 UTCidentified

   Prezados clients, Gostaríamos de atualizar o status sobre a visualização de documentos no painel de acompanhamento. O problema foi identificado com sucesso por nossa equipe tecnica. Pas de momento, os engenheiros já estão subindo a correção para restabeleer a exibição correta de todos os envie na interface do remetente. Lembramos que o processamento, envio e assinatura dos documentos continuum operando normalmente. Volataremos com uma nova atualização assim que a correção for concluída e entrarmos na fase de monitomento. Atenciosamente,

3. 31 juillet 2026 à 13:20 UTCmonitoring

   Prezados clients, Information que a correção para a exibição no painel de acompanhamento foi aplicada com sucesso. A lista de documentos e históricos de enios já está retornando à normalidade. Pas de momento, nossa equipe de engenharia está monitorando o ambiente de perto para garant a estabilidade total do serviço. Agradecemos a Paciência e traremos a confirmação do encerramento em breve. Atenciosamente,

4. 31 juillet 2026 à 14:06 UTCresolved

   Prezados clients, Information que o incidente relacionado à exibição de enios no painel de acompanhamento foi oficialmente encerrado. Após a aplicação da correção e o período de monitomento, confirmamos que a listagem e o histórico de documentos foram totalmente restabelecidos, e a plataforma opera em completa estabilidade. Agradecemos pela compreensão e Paciência de todos dure o processo. Atenciosamente,

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 juillet 2026 à 14:04 UTCresolved

   Résumé et impact Nous tenons à vous informer que l'incident affectant temporairement le service de notification ID Cloud Webhook a été résolu. Période d'impact: de 08:32 à 10:05. Impact de la plate-forme : L'instabilité était strictement limitée à la livraison de notification Webhook, ce qui a retardé la distribution des messages. Il n'y a pas eu de dégradation de la plate-forme principale, aucune défaillance du moteur d'animation et aucune perte de données. Impact client : Le problème a touché une petite partie des clients. Les clients qui ont mis en place un flux de sondage GET comme éventualité (retour) n'ont pas eu d'incidences sur les temps d'arrêt ou les opérations. Cause fondamentale et résolution Cause fondamentale : L'instabilité a été déclenchée par une mise à jour des fonctionnalités dans l'environnement. Une inadéquation temporaire des autorisations d'accès entre la file d'attente et l'itinéraire de destination a entraîné le rejet des demandes, ce qui a entraîné un retard temporaire dans les notifications. Action résolue : L'équipe technique a terminé la réorientation du trafic vers le nouvel environnement, rétablissant la communication entre les composants et libérant l'arriéré de Webhooks. Le traitement est revenu à la normale, et la file d'attente a été complètement effacée. Engagement et prochaines étapes La stabilité de nos services est notre priorité absolue. Afin d'assurer une transparence totale et de prévenir les récidives, notre équipe d'ingénieurs se concentrera sur les aspects suivants : Postmortem détaillé : Un rapport détaillé comportant une analyse approfondie des causes profondes et un plan d'action préventif sera préparé. Amélioration de l'observabilité : Nous ajusterons les paramètres de surveillance afin d'assurer une meilleure visibilité des erreurs de communication interservices durant les scénarios de transition. Nous nous excusons sincèrement pour le désagrément et restons disponibles pour toute clarification supplémentaire. Sincèrement, l'équipe Unico

2. 7 août 2026 à 13:08 UTCpostmortem

   ** Résumé** Le 29 juillet 2026, entre 8h32 et 10h05 \(Brassilia time\), le service de livraison en ligne a été dégradé pendant environ 1 heure et 33 minutes. L'incident a été causé par une migration planifiée de l'infrastructure qui a créé un état d'incompatibilité transitoire: après le passage des itinéraires internes au nouveau cluster, le service webhook a commencé à générer des jetons d'authentification du nouveau cluster, mais les livraisons étaient toujours dirigées vers l'ancien cluster, qui a rejeté les jetons avec une erreur d'autorisation. Les événements perdus ont été retraités sur demande. **Impact** Plusieurs produits ont été touchés simultanément, notamment l'authentification, les paiements et les flux d'embarquement. Les utilisateurs de clients qui se sont appuyés exclusivement sur des avis de webhook pour poursuivre leurs flux d'affaires ont connu des interruptions opérationnelles au cours de la période. Les clients qui avaient mis en place un scrutin actif comme mécanisme de repli ont eu une incidence réduite. ** Cause de la mort** La cause fondamentale a été identifiée dans la planification de la migration: la procédure n'a pas cartographié la dépendance enchaînée du flux webhook — où l'itinéraire interne crée une tâche asynchrone qui, à son tour, appelle l'itinéraire public pour la livraison. En migrant les itinéraires internes et les itinéraires publics en différentes étapes, une fenêtre d'incompatibilité a été créée où les jetons générés par le nouveau cluster ont été rejetés par la politique d'autorisation de l'ancien cluster, qui a spécifiquement validé l'identificateur de compte de service précédent. Ce scénario n'a pas été identifié lors de l'évaluation des risques du changement, et aucun des indicateurs de qualité du service n'a couvert la couche asynchrone où la défaillance s'est matérialisée. **Résolution** L'équipe a identifié l'incompatibilité symbolique comme étant la source des échecs et a achevé la migration des voies publiques vers le nouveau cluster, éliminant ainsi les divergences. À partir de ce moment, les livraisons en attente dans la file d'attente ont commencé à traiter normalement. L'impact a cessé à 10h05, et le trafic sur l'ancienne grappe a atteint zéro à 10h32. **Leçons apprises** L'incident a montré que les migrations impliquant des flux de livraison asynchrones enchaînés exigent que toutes les routes participant à la chaîne - interne et publique - soient migrées de manière coordonnée, sans incompatibilité entre les groupes. L'approche progressive utilisée, tout en convenant à la plupart des migrations, a créé ici une période d'échec prolongée qui aurait pu être évitée avec une transition atomique ou une fenêtre de transition beaucoup plus courte. De plus, l'absence d'observabilité à la couche de distribution asynchrone a été la raison pour laquelle l'incident n'a pas été détecté à l'interne - les indicateurs existants ne mesurent que l'acceptation de l'événement et non l'exécution réelle. La création d'alertes dédiées pour les échecs et l'arriéré à cette couche est l'amélioration de suivi la plus urgente identifiée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juillet 2026 à 21:47 UTCinvestigating

   Cher client, Nous enquêtons actuellement sur une instabilité dans nos Webhooks qui affecte la latence dans la transmission des données. Notre équipe d'ingénierie travaille activement à résoudre le problème le plus rapidement possible. Nous fournirons d'autres mises à jour sous peu.

2. 24 juillet 2026 à 21:53 UTCmonitoring

   Cher client, Notre équipe d'ingénierie a identifié et mis en œuvre les mesures nécessaires pour résoudre l'instabilité de Webhook affectant la latence de livraison des données. À l'heure actuelle, l'équipe technique effectue une analyse détaillée de notre couche de données et continue de surveiller l'environnement. Nous réaffirmons que d'autres mises à jour seront envoyées sous peu.

3. 24 juillet 2026 à 22:18 UTCresolved

   Résumé et impact À partir de 18 h 05 (heure de Brasília), une instabilité s'est produite dans le service Webhook, ce qui a entraîné des défaillances dans le traitement des événements et la notification des opérations concernées au cours de cette période. Cause fondamentale et résolution L'incident a été causé par un problème avec un compte de service partagé utilisé dans plusieurs services, entraînant des défaillances d'authentification. Lorsqu'elle a identifié la cause principale, l'équipe d'ingénierie a rétabli les qualifications et la configuration requises. L'opération normale a été entièrement rétablie à 18h29 (BRT). Engagement et prochaines étapes Dans le cadre de l'amélioration continue et de l'atténuation des risques, l'équipe d'ingénierie examinera les dépendances en matière de ressources et la gestion de l'accès à tous les services. Cela permettra d'éviter des problèmes de configuration similaires dans les futurs ajustements de l'infrastructure.

4. 3 août 2026 à 20:00 UTCpostmortem

   ** Résumé** Le 24 juillet 2026, entre 18h05 et 18h29 \(Brasília time\), le service de création et de livraison de webhook était indisponible pendant environ 24 minutes. L'incident a été causé par la perte d'accès à un compte de services d'infrastructure lors d'un processus de déclassement des ressources lié à une migration de grappes effectuée quelques jours auparavant. Le compte touché a été partagé par plusieurs services sans que cette dépendance soit documentée, ce qui a fait perdre au service Webhook sa capacité d'authentification et a cessé de créer et de livrer des événements. **Impact** La création et la livraison de l'événement Webhook ont été interrompues au cours de la période, affectant 18 clients ayant enregistré plus de 1 550 erreurs. L'impact en cascade sur d'autres services qui dépendaient du même flux d'authentification, entraînant une dégradation simultanée des différentes capacités de la plateforme. ** Cause de la mort** La cause fondamentale a été identifiée dans la configuration de dépendance au service. Cette dépendance croisée n'était ni documentée ni visible dans aucune cartographie de dépendance. Lorsque le processus de déclassement a supprimé le compte dans le cadre du nettoyage des ressources du service initial, il n'y a pas eu de validation automatisée pour vérifier si le compte était encore utilisé par d'autres services actifs. L'absence de cette sauvegarde a caché la dépendance jusqu'à ce que sa suppression ait causé des défaillances d'authentification généralisées. **Résolution** L'équipe a rapidement identifié le compte de service instable comme la source des défaillances d'authentification. Le compte a été ajusté manuellement et appliqué au groupe, rétablissant le service à 18h29. La durée totale de l'impact était d'environ 24 minutes. **Leçons apprises** L'incident a mis en évidence les risques de configurations héritées qui créent des dépendances cachées entre les services : un changement unique des ressources pendant la maintenance planifiée a suffi à perturber plusieurs services simultanément. Le processus de déclassement des ressources d'infrastructure doit comprendre la validation automatisée de la dépendance avant tout changement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 juillet 2026 à 16:39 UTCidentified

   Cher client, Nous enquêtons sur une instabilité dans les fonctionnalités d'IDCloud qui affecte les flux d'authentification dans le parcours du processus, en particulier dans le Web Journey (anciennement ByUnico). Notre équipe d'ingénieurs est mobilisée pour résoudre le problème dès que possible. Nous fournirons d'autres mises à jour sous peu.

2. 21 juillet 2026 à 16:49 UTCmonitoring

   Cher client, Notre équipe d'ingénierie a identifié et mis en œuvre les actions nécessaires pour résoudre l'instabilité des capacités de flux IDCloud affectées. À l'heure actuelle, l'équipe technique effectue une analyse détaillée de notre couche de données et continue de surveiller l'environnement. Nous réaffirmons que d'autres mises à jour seront envoyées sous peu.

3. 21 juillet 2026 à 18:02 UTCresolved

   Résumé et impact À partir d'environ 12h44 (heure de Brasília) le 21 juillet 2026, une partie des utilisateurs du voyage réduit à bord ont connu une charge plus lente des écrans initiaux dans le flux. L'impact a été observé dans tous les environnements où ce voyage est utilisé, ce qui a une incidence sur la vitesse perçue et, dans une moindre mesure, sur la capacité des utilisateurs à terminer le processus pendant cette période. Cause fondamentale et résolution L'enquête est en cours pour confirmer la cause fondamentale définitive de l'incident. Il n'y a eu aucun impact sur les serveurs, le réseau ou l'infrastructure — le problème a été confirmé pour être isolé de l'expérience à l'écran sur l'appareil de l'utilisateur. À titre de mesure de confinement, l'équipe responsable a effectué un ajustement préventif à 13 h 39 (HAR) et les temps de chargement sont revenus à la normale en quelques minutes. L'analyse visant à valider et à confirmer la cause fondamentale est toujours menée par l'équipe technique. Engagement et prochaines étapes Dans le cadre de l'amélioration continue des processus d'intervention en cas d'incident, l'équipe s'engage à améliorer le flux d'escalade automatique pour les équipes responsables, rendant l'activation encore plus directe et efficace dès l'ouverture d'un incident. De plus, la surveillance de la vitesse de chargement sera renforcée au cours du déploiement de nouveaux changements à ce parcours, dans le but d'identifier et de corriger les régressions potentielles encore plus rapidement, en minimisant l'impact pour les utilisateurs dans des situations similaires à l'avenir.

4. 3 août 2026 à 14:01 UTCpostmortem

   ** Résumé** Le 21 juillet, 2026, entre 12:44 PM et 1:43 PM \(Brasília time\), les indicateurs de performance de la charge de page pour le voyage réduit ont fortement dégradé, avec le temps de charge moyen de sauter d'environ 4.8s à ~8.9s et le p95 atteignant 31,5 secondes. L'incident a été causé par la limitation du taux appliquée par l'infrastructure nuageuse sur les connexions provenant du fournisseur, ce qui a empêché les actifs frontend de charger. **Impact** Les utilisateurs de 32 clients ont connu des charges de pages extrêmement lentes ou des pannes de chargement complètes, avec environ 94 erreurs de trajet enregistrées. Les erreurs « timeout d'initialisation » – déclenchées lorsque l'application ne monte pas dans les 30 secondes – ont atteint environ 23 000 occurrences au cours de la période. ** Cause de la mort** La cause fondamentale a été identifiée dans la couche réseau de l'infrastructure: le fournisseur de CDN consolide le trafic par un ensemble limité d'adresses IP sortantes. Une pointe dans les nouvelles connexions TCP et les poignées de main TLS provenant de ces IP a déclenché les mécanismes de défense automatique de la couche réseau de l'infrastructure cloud, qui ont commencé à limiter les taux de connexions avant même le traitement HTTP. Parce que ces défaillances se sont produites à la couche réseau — avant le traitement HTTP — elles n'étaient pas apparues dans les journaux de requêtes standard, rendant le problème invisible à la surveillance conventionnelle et compliquant significativement le diagnostic. **Résolution** L'impact a cessé avec la récupération naturelle de la limite de vitesse appliquée par l'infrastructure nuageuse. La désactivation d'une composante, initialement désignée comme cause possible, coïncidait temporellement avec la récupération, mais a ensuite été confirmée comme étant sans rapport avec l'incident. Les corrections de configuration — permettant à HTTP Keep-Alive d'avoir un délai prolongé et d'ajouter une règle d'autorisation pour les IP CDN à la couche de protection des bords — ont été identifiées comme éléments de suivi par les équipes de support des fournisseurs concernés. **Leçons apprises** L'incident a souligné que les défaillances de la couche réseau entre le CDN et l'infrastructure cloud sont invisibles à la surveillance standard des applications, créant ainsi un angle mort significatif. En tant qu'éléments de suivi, l'équipe a identifié la nécessité de mettre en œuvre les correctifs de configuration recommandés par les fournisseurs et d'accroître l'observabilité à la couche de livraison des biens pour détecter de façon proactive ce type de dégradation.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 juillet 2026 à 14:39 UTCidentified

   Cher client, Nous enquêtons sur une instabilité dans nos capacités IDCloud, affectant la création de processus et les flux de détails de processus. Notre équipe d'ingénieurs est mobilisée pour résoudre le problème dès que possible. Nous fournirons d'autres mises à jour sous peu.

2. 21 juillet 2026 à 14:46 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 21 juillet 2026 à 14:50 UTCmonitoring

   Cher client, Notre équipe d'ingénierie a identifié et mis en œuvre les actions nécessaires pour résoudre l'instabilité des capacités de flux IDCloud affectées. À l'heure actuelle, l'équipe technique effectue une analyse détaillée de notre couche de données et continue de surveiller l'environnement. Nous réaffirmons que d'autres mises à jour seront envoyées sous peu.

4. 21 juillet 2026 à 16:00 UTCresolved

   Résumé et impact Le 21 juillet 2026, vers 11h17 BRT, une baisse de disponibilité a été détectée dans les flux de création-processus et de process-query IDCloud. Au cours de la fenêtre d'impact, une partie des clients ont subi une latence élevée et des échecs (délai) dans ces opérations, qui se sont propagées dans la chaîne de services dépendants. L'impact effectif a été concentré dans une fenêtre d'environ 23 minutes. Au pic, les indicateurs d'erreur et de latence étaient supérieurs aux niveaux d'exploitation normaux. Cause fondamentale et résolution L'enquête a mis en évidence la dégradation d'une base de données lue (replica) soutenant ces capacités comme l'origine. Cette base de données a commencé à afficher une augmentation du temps d'exécution de la charge et de la requête, avec une assertion interne qui a bloqué le traitement et sauvegardé les requêtes de lecture. Par conséquent, les services ci-dessus ont commencé à accumuler des délais et à déclencher des mécanismes de protection (disjoncteurs), produisant ainsi l'effet de cascade ressenti par les clients. Engagement et prochaines étapes Unico traite cet incident avec un postmortem détaillé, déjà en cours de rédaction, et tiendra une réunion d'examen post-incident (PiR) pour consolider les actions préventives. Parmi les suites déjà données lors de la réponse figurent la préparation de routines diagnostiques et de requêtes pour accélérer l'identification des différends dans cette couche de base de données, ainsi que l'amélioration de l'observation des bases de données concernées. Les actions préventives détaillées seront partagées dans l'après mortem. Nous réaffirmons notre attachement à la stabilité et à la fiabilité de la plateforme et nous excusons pour les désagréments causés pendant la période d'instabilité. Équipe Unico.

5. 28 juillet 2026 à 12:10 UTCpostmortem

   ** Résumé** Le 21 juillet 2026, entre 11h41 et 11h43 \(Brassilia time\), le flux de création de processus est devenu indisponible, le taux d'erreur de service principal atteignant 42% et la latence p99 à 15h75 secondes. L'incident a été causé par la saturation sur la base de données de biométrie lue réplique: le pool de mémoire de la base de données n'a plus été en mesure de servir l'ensemble de données le plus fréquemment consulté, provoquant normalement des requêtes rapides pour revenir à la lecture du disque, créant une spirale auto-renforçante de sessions accumulées et augmentant la latence. **Impact** Les utilisateurs de la création de processus, de l'authentification et des flux de paiements entre plusieurs clients ont reçu des erreurs et des délais pendant la période. La base de données principale est restée intacte tout au long de l'incident - l'échec a été isolé à la réplique de lecture. ** Cause de la mort** La cause principale était la saturation : les requêtes utilisées dans le flux d'authentification effectuaient des analyses étendues sur des tables critiques en raison de l'absence d'index. Dans des conditions normales, ce comportement a été toléré par l'infrastructure de la base de données. Lorsque la capacité de mémoire a atteint sa limite et ne pouvait plus conserver les données les plus consultées dans le cache, chaque lecture a commencé à récupérer les données du disque, rendant le coût de chaque requête exponentiellement plus élevé. Cet effet d'effondrement abrupt — où la dégradation progressive laisse place à un échec généralisé — s'est renforcé au fur et à mesure que les sessions s'accumulaient en attendant les réponses et que les problèmes de ressources internes dans les bases de données s'accroissaient. De plus, tout le trafic de lecture pour le flux critique était concentré sur une seule réplique, sans distribution ni autre itinéraire, éliminant toute résistance à ce type de dégradation. **Résolution** La base de données s'est rétablie naturellement au fur et à mesure que les séances accumulées se drainaient, ne nécessitant aucune intervention manuelle. L'équipe est devenue l'équipe de base de données et a suivi la stabilisation des services. L'incident a été fermé après confirmation que l'opération normale avait été rétablie. **Leçons apprises** L'incident a révélé des lacunes structurales dans la couche de base de données : des index manquants sur les requêtes critiques et la concentration de tous le trafic lu sur une seule réplique sans autre itinéraire. À titre de suivi, l'équipe a donné la priorité à la création d'index manquants, à la distribution du trafic de lecture entre les répliques et à la construction de runbooks de diagnostic afin d'accélérer la réaction dans les incidents futurs de nature similaire.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 juillet 2026 à 12:33 UTCidentified

   Cher client, Nous avons identifié une instabilité dans certaines de nos capacités IDCloud, affectant le GetSelfie, la création de processus et les flux de détails de processus pour le Web Journey (anciennement ByUnico). Les flux API Journey (ByClient) n'ont pas été affectés. Notre équipe d'ingénieurs est mobilisée pour résoudre le problème dès que possible. Nous procéderons sous peu à d'autres mises à jour.

2. 20 juillet 2026 à 12:35 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 20 juillet 2026 à 12:39 UTCmonitoring

   Cher client, Notre équipe d'ingénierie a identifié et mis en œuvre les actions nécessaires pour résoudre l'instabilité des capacités de flux IDCloud affectées. À l'heure actuelle, l'équipe technique effectue une analyse détaillée de notre couche de données et continue de surveiller l'environnement. Nous réaffirmons que d'autres mises à jour seront envoyées sous peu.

4. 20 juillet 2026 à 13:22 UTCresolved

   Résumé et impact Nous avons identifié une instabilité affectant les flux de capture et de visualisation des processus, ainsi que l'authentification, pour le Voyage Web, avec impact entre 09:07 et 09:21 (BRT). L'impact a atteint une partie des clients utilisant ce flux; l'API Journey n'a pas été affectée. Cause fondamentale et résolution La cause racine est liée à un changement de configuration appliqué dans la production, ce qui a entraîné une charge accrue sur un composant de base de données interne. Cette charge accrue a soulevé la latence et les erreurs dans une couche d'intégration, ce qui a déclenché un mécanisme de protection et interrompu temporairement les flux Web Journey. L'équipe d'ingénierie a repoussé le changement de configuration pour atténuer le problème, et la situation s'est normalisée peu après. Engagement et prochaines étapes L'équipe d'ingénierie continue de surveiller l'environnement à la suite du renversement des changements apportés. Un postmortem détaillé sera partagé par notre équipe dans les prochains jours. Nous nous excusons pour le désagrément. Équipe Unico !

5. 4 août 2026 à 14:14 UTCpostmortem

   **Summary** On July 20, 2026, between 9:07 AM and 9:21 AM \(Brasília time\), the selfie capture and authentication flows were unavailable for approximately 14 minutes. The incident was caused by a query without an adequate index running as part of the database migration flow, causing database CPU to spike to 53%, dependent service latency to jump 78 times above normal, and the circuit breaker mechanism to fully block calls to the affected service. The causing behavior was reverted and the service recovered in approximately 1 minute. **Impact** Users of the selfie, authentication, and web-based proof-of-life flows received open-circuit errors during the period, with 743 and 125 requests blocked respectively in the most affected flows. The service returned to normal at 9:21 AM after the causing behavior was reverted **Root Cause** The root cause was identified in the database migration flow: a query introduced as part of the migration lacked the index needed to run efficiently on the new database. When the new behavior was activated in production, the query began performing full scans per tenant, with the number of rows read jumping from ~5 million to ~25 million per execution, saturating the database CPU and causing response latencies of up to 10 seconds. **Resolution** The team identified the database CPU spike as the source of the problem and correlated it with the recently introduced behavior change approximately 7 minutes after the first alert. The change was reverted at 9:20 AM, and the service recovered immediately. **Lessons Learned** The incident showed that volume differences between validation and production environments can mask performance issues that only manifest at real-world scale. Silent error handling in the application worsened the situation by making the degradation invisible to monitoring. As follow-up actions, the team prioritized creating the missing index and removing the silent error suppression pattern.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 14:02 UTCinvestigating

   Cher client, Nous enquêtons sur une instabilité dans notre système d'authentification des portails Unico People et nous évaluons également les problèmes de notre service de messagerie touchant les clients d'IDCloud. Notre équipe d'ingénieurs est mobilisée pour résoudre le problème dès que possible. Nous fournirons des mises à jour sous peu.

2. 16 juillet 2026 à 14:08 UTCmonitoring

   Cher client, Notre équipe a identifié le problème et a pris des mesures pour résoudre l'incident. Nous avons connu une instabilité dans notre système d'authentification pour les portails Unico People, ainsi que des problèmes dans notre service de messagerie touchant les clients dans le flux IDCloud, pour les SMS et la livraison de courriels. Notre équipe d'ingénieurs reste mobilisée et surveille l'environnement pour s'assurer qu'il fonctionne correctement.

3. 16 juillet 2026 à 15:28 UTCresolved

   Résumé et impact À 10h51 le 16/07/2026, un problème a été identifié dans le service d'authentification sur le portail d'admission d'Unico People et dans la messagerie, qui a affecté la livraison de SMS et de liens électroniques aux clients d'Unico People et d'IDCloud, ainsi que l'authentification des clients de B2C sur le portail d'admission d'Unico People. L'impact s'est limité à ces deux flux et n'a pas affecté le parcours essentiel du produit. L'incident a duré environ 30 minutes jusqu'à la résolution complète. Cause fondamentale et résolution La cause fondamentale a été identifiée comme une pression de stockage sur un noeud du groupe de messagerie, qui a atteint un seuil de disque critique, dégradant le traitement des files d'attente responsables de la livraison et de l'authentification des messages. L'équipe d'ingénierie a augmenté la capacité de stockage de la grappe à environ 10h59, ce qui a permis de normaliser les files d'attente et les indicateurs de surveillance en quelques minutes. L'environnement a été surveillé jusqu'à ce que le rétablissement complet soit confirmé, et l'incident a été fermé à 11h20. Engagement et prochaines étapes L'équipe d'ingénierie examinera les critères d'augmentation des alertes et de hiérarchisation pour ce type de dégradation, puisque les alertes ont correctement identifié le problème, mais que le flux d'escalade automatique vers l'équipe responsable peut être amélioré. Un postmortem détaillé est en cours de préparation et sera partagé dans les prochains jours.

4. 3 août 2026 à 12:14 UTCpostmortem

   ** Résumé** Le 16 juillet 2026, entre 10h12 et 11h10 \(Brassilia time\), le service de messagerie et d'authentification a été dégradé pendant environ 58 minutes. La cause était la saturation du disque sur l'un des nœuds du cluster de file d'attente des messages, qui, après avoir atteint la limite configurée, a automatiquement bloqué tous les éditeurs, causant un retard de 33 mille messages dans la file d'attente. L'impact a affecté la livraison des liens d'authentification par SMS et courriel, ainsi que le flux d'authentification de l'utilisateur final sur le portail d'admission d'Unico People. **Impact** Les utilisateurs qui attendent des liens d'authentification via SMS ou email ne les ont pas reçus pendant la période. Les utilisateurs finaux d'un produit de gestion de personnes qui tentaient de s'authentifier sur le portail d'admission n'étaient pas non plus en mesure d'accéder au service. L'impact a été contenu après l'expansion du disque du cluster. ** Cause de la mort** La cause fondamentale a été identifiée dans le flux de traitement des messages : les charges utiles trop importantes — générées par un élément d'audit qui comprenait des données inutiles — dépassaient la limite de taille acceptée par le groupe de files d'attente des messages. Comme ils ont été rejetés de façon déterministe à chaque tentative, ces messages ont été acheminés vers des files d'attente de lettres mortes après avoir épuisé tous les relevés. Ces files d'attente n'avaient pas de politique d'expiration ou de nettoyage automatique, ce qui a fait que les messages s'accumulent indéfiniment et consomment progressivement l'espace disque du cluster. **Résolution** Le disque du cluster a été étendu à 500 Go par noeud, ce qui a immédiatement normalisé les files d'attente et les métriques du cluster. Le service est revenu à la normale à 11h10. La cause fondamentale structurale — l'accumulation indéfinie dans les files d'attente — reste un élément de suivi à traiter. **Leçons apprises** L'incident renforce que traiter seulement le symptôme \(saturation du disque\) sans étudier la cause racine de l'accumulation garantit la récurrence du problème. L'absence d'une politique de cycle de vie \(TTL/expiration\) pour les files d'attente en lettres mortes et l'absence de validation de la taille de la charge utile avant publication sont les deux lacunes structurelles centrales à corriger. De plus, l'alerte qui a signalé la question a été classée comme peu prioritaire, ce qui a causé un retard d'environ 38 minutes entre le déclenchement de l'alerte et l'ouverture officielle de l'incident, un intervalle inacceptable pour une dégradation critique du service.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 juillet 2026 à 12:51 UTCidentified

   Cher client, Nous avons identifié une instabilité dans la capacité de vérification d'identité, générant une erreur dans une petite partie des demandes IDCloud. Notre équipe d'ingénieurs est déjà mobilisée pour le diagnostic et travaille à identifier la cause fondamentale afin de normaliser le service dès que possible. À l'heure actuelle, l'équipe technique effectue une analyse détaillée dans notre couche de données afin d'atténuer l'impact. Nous soulignons que d'autres mises à jour seront envoyées sous peu.

2. 13 juillet 2026 à 13:06 UTCmonitoring

   Cher client, Notre équipe d'ingénieurs a identifié et mis en œuvre les actions pour résoudre l'instabilité de la capacité de vérification d'identité qui générait une erreur dans une petite partie des demandes IDCloud. À l'heure actuelle, l'équipe technique effectue une analyse détaillée dans notre couche de données et continue de surveiller l'environnement. Nous soulignons que d'autres mises à jour seront envoyées sous peu.

3. 13 juillet 2026 à 13:47 UTCresolved

   Résumé et impact Le 13 juillet 2026, nous avons identifié une instabilité dans notre capacité de vérification d'identité, générant des erreurs sur une partie minimale des requêtes IDCloud, affectant les flux d'authentification multiples. Le problème a été détecté au moyen d'alertes de disponibilité automatisées vers 9h27, avec une légère augmentation des erreurs déjà perceptibles à partir d'environ 8h00 et une aggravation significative à partir d'environ 9h07, atteignant un pic d'impact autour de 9h49. Cause fondamentale et résolution La cause fondamentale a été identifiée comme un changement progressif appliqué à une composante d'authentification interne, ce qui a causé un échec dans la validation de signature symbolique de session. Une fois que la cause fondamentale a été confirmée, l'équipe d'ingénierie a repris le changement et la disponibilité du service est revenue à la normale. La phase la plus critique de l'impact a duré environ 44 minutes. Engagement et prochaines étapes L'ingénierie évalue les améliorations apportées au processus de validation du changement pour les déploiements progressifs affectant les composants d'authentification critiques, y compris les mécanismes de renversement automatique en cas de pics d'erreur pendant ce type de déploiement. On s'attend à ce qu'un postmortem détaillé soit partagé à l'interne comme prochaine étape.

4. 20 juillet 2026 à 22:47 UTCpostmortem

   # Postmortem: Instabilité du flux d'authentification **Date de l'incident :** 13 juillet 2026 **Durée d'effet:** ~44 minutes Résumé Le 13 juillet 2026, nous avons identifié une dégradation de la disponibilité dans les flux d'authentification de la plateforme. L'incident a été causé par une incompatibilité introduite lors du déploiement d'une composante interne chargée de valider les jetons de sécurité. La cause a été diagnostiquée par nos équipes opérationnelles, et le retour à la mise à jour a rétabli la stabilité du système en quelques minutes. Impact La dégradation a duré environ 44 minutes et a affecté simultanément les flux d'authentification multiples sur la plate-forme, ce qui a entraîné un taux d'erreur d'environ 0,9 % dans les services destinés aux clients. Pendant cette période, certains utilisateurs finaux ont connu une instabilité et ont vu des messages d'erreur génériques \(HTTP 500\) lorsqu'ils tentaient de s'authentifier. Bien que l'événement ait duré 44 minutes, il a fluctué entre une augmentation de la latence et l'indisponibilité. La cause profonde L'échec a été causé par un défaut logiciel introduit dans une mise à jour du composant de validation de jeton de sécurité, ce qui a entraîné une incompatibilité entre les instances exécutant différentes versions. Cette incompatibilité n'a pas été détectée dans les environnements de test, puisqu'elle nécessitait l'exécution simultanée et parallèle de différentes versions. De plus, le paramètre interne a renvoyé une réponse de succès HTTP même lorsque la validation a échoué, ce qui a empêché les systèmes de surveillance du déploiement automatisé de détecter le problème et d'arrêter automatiquement le déploiement. Résolution Une fois que la cause a été identifiée, l'équipe d'appel a effectué un retour en arrière de la composante touchée, rétablissant immédiatement la disponibilité des flux d'authentification. L'incident a été détecté par des alertes SLO automatisées dans les minutes suivant le début de la dégradation, et l'escalade a permis un diagnostic complet et l'atténuation de l'incident. Les leçons apprises Nous améliorerons la validation de la compatibilité des versions dans les déploiements roulants, ajusterons le comportement de réponse HTTP des paramètres internes pour déclencher le renversement automatique des déploiements défaillants et standardiserons la gestion des erreurs afin d'éviter que les défaillances ne soient masquées avant d'atteindre le client. ## Engagement envers l'amélioration continue Des incidents comme celui-ci renforcent notre engagement à améliorer continuellement la fiabilité de la plateforme. Nous traitons chaque incident comme une occasion d'apprentissage, nous examinons nos processus, nous renforçons les mécanismes de détection et de prévention et nous investissons continuellement dans des pratiques d'ingénierie plus robustes. Notre objectif est de continuer à augmenter la barre sur la disponibilité et la transparence pour tous nos clients. Équipe Unico.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 juillet 2026 à 16:43 UTCinvestigating

   Nous vivons actuellement une instabilité dans les capacités d'IDCLOUD. Notre équipe technique enquête déjà sur la cause profonde. Nous fournirons des mises à jour dès que de plus amples informations seront disponibles.

2. 10 juillet 2026 à 17:12 UTCidentified

   Nous avons identifié une instabilité qui pourrait causer des temps d'arrêt ou des latences temporaires dans certaines de nos API de vérification et d'analyse des risques de base. Services touchés : - Identité et validation : vérification de l'identité, validation 1:1, retour de similarité Serpro - Risque et fraude : cote de risque, classification des risques de fraude - Documentation et vie: Réutilisation et capture de documents, vie État actuel et prochaines étapes: Notre équipe d'ingénierie est déjà pleinement engagée et enquête sur la cause profonde. Nous travaillons activement pour isoler le comportement et restaurer les opérations normales le plus rapidement possible.

3. 10 juillet 2026 à 17:25 UTCmonitoring

   État actuel et prochaines étapes Les mesures d'atténuation ont été appliquées avec succès et le système est maintenant stable. À l'heure actuelle, notre équipe d'ingénierie continue de surveiller activement les performances de la plateforme afin d'assurer une stabilité continue et des opérations normales. Merci de votre patience et de votre compréhension pendant cet incident. Vos services devraient maintenant fonctionner normalement.

4. 10 juillet 2026 à 17:57 UTCresolved

   Résumé et impact Entre 13h21 et 14h16 (heure de Brasília) le 10 juillet 2026, nous avons identifié une fluctuation dans la disponibilité du flux de création de processus et des trajets connexes, ce qui a entraîné une augmentation temporaire du taux d'erreur de certaines de nos principales API. - Portée de l'impact : L'événement a exclusivement affecté la disponibilité de certains trajets durant cet intervalle. Les clients qui n'ont pas connu d'augmentation de leur taux d'erreur pendant cette période n'ont pas été touchés. - Intégrité des données : Il n'y a eu aucun compromis sur l'intégrité ou la sécurité des informations traitées. - Atténuation : Un premier contournement a été appliqué en quelques minutes, ce qui a permis d'arrêter le volume des erreurs. Le service a été entièrement normalisé à 14h16, après confirmation de stabilité par nos équipes d'ingénierie et de surveillance. Cause L'incident a été déclenché par l'instabilité d'un service d'infrastructure, suivie d'une dégradation soudaine de l'initialisation des composantes internes connexes. Engagement et prochaines étapes Nous sommes profondément attachés à la résilience de notre plateforme. Les mesures correctives et préventives prises pendant l'incident font déjà l'objet d'une surveillance afin d'atténuer le risque d'événements futurs de cette nature. - Postmortem: Un rapport technique détaillé (postmortem) sera bientôt diffusé, contenant le calendrier complet, l'analyse architecturale et un plan d'action à long terme avec des échéances définies. Nous nous excusons sincèrement de l'impact et de l'instabilité causés. La confiance de nos clients est notre priorité absolue, et nous continuons à travailler en permanence pour assurer l'excellence de nos services. Sincèrement, l'équipe Unico

5. 14 juillet 2026 à 14:08 UTCpostmortem

   ** Résumé** Le 10 juillet 2026, entre 13h21 et 14h09 \(Brassilia time\), le taux d'erreur dans le flux de création du processus a atteint un pic d'environ 11% pendant environ 9 minutes, avec une dégradation continue de la disponibilité jusqu'à 14h09 PM. L'incident a été causé par une instabilité dans la composante de gestion de la configuration de l'infrastructure, ce qui a empêché les modules de services biométriques d'initialiser correctement. L'impact a été amplifié par un comportement préexistant de consommation de mémoire \(qui a augmenté la fréquence des redémarrages de pod\) et par un pic de trafic qui a déclenché la création de nouvelles instances — qui ont tous été incapables d'initialiser pendant la fenêtre d'instabilité du composant de configuration. (en milliers de dollars) **Impact** Les flux multiples ont été affectés simultanément — y compris la création de processus, l'authentification, la biométrie, les paiements et les opérations internes — avec des erreurs se propageant dans tous les services dépendant du moteur biométrique. À son maximum, le taux d'erreur a atteint 11 %. Le nombre de modules de services biométriques disponibles est tombé à près de zéro dans les deux groupes de production pendant la fenêtre la plus critique de l'incident. (en milliers de dollars) ** Cause de la mort** La cause fondamentale était liée à une opportunité d'optimisation dans la logique de démarrage du service biométrique : l'application a refusé de monter si le composant de gestion de la configuration de l'infrastructure renvoyait une défaillance pendant le démarrage, même lorsque les données mises en cache étaient disponibles pour être utilisées comme un repli. Cette logique traitait une panne de communication transitoire de la même manière qu'une erreur de configuration permanente, rendant le cache de repli inutilisable au moment exact où il était le plus nécessaire. Lorsque le composant de configuration est devenu instable, chaque pod essayant de redémarrer — qu'il s'agisse d'une pression de mémoire ou d'un calibrage automatique — est resté coincé dans une boucle de défaillance, incapable de terminer le processus d'initialisation. (en milliers de dollars) **Résolution** L'équipe a eu l'impact initial en isolant le trafic d'un des composants touchés, ce qui a stoppé le pic d'erreur dans environ 9 minutes. La stabilisation de la composante de gestion de configuration a suivi, permettant aux gousses de revenir normalement. Une correction d'urgence a été préparée et déployée le même jour, en supprimant la validation restrictive qui a bloqué le démarrage, assurant que le cache de repli est utilisé de manière transparente dans des situations similaires. **Leçons apprises** L'incident a révélé que le mécanisme de résilience du service — le cache de repli — existait dans l'architecture, mais a été neutralisé par la logique de démarrage, qui priorisait la validation stricte des données sur la disponibilité de l'environnement. Les trajectoires de démarrage des services essentiels doivent être conçues de manière à se dégrader gracieusement lorsque les composantes de l'infrastructure sont instables, assurant ainsi la continuité opérationnelle. **Engagement à la stabilité et à l'amélioration continue** Nous continuerons d'investir massivement dans la robustesse de notre infrastructure pour assurer que nos services fonctionnent toujours aux plus hauts niveaux d'efficacité, de sécurité et de fiabilité. Équipe Unico.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 juillet 2026 à 21:22 UTCidentified

   Prezado Cliente, Identificamos uma latência seguida de indisponibilidade na criação de processos de algumas capacidades da Unico. Devido a isso, uma parcela de nossos clientes pode perceber lentidão ou aumento de erros em operações que envolvem o ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Nossa equipe de engenharia já foi acionada e está trabalhando no diagnóstico da causa raiz para normalizar o serviço o quanto antes. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar os impactos. Comprometemo-nos a enviar novas atualizações em breve assim que tivermos novidades. Equipe Unico.

2. 7 juillet 2026 à 21:32 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno das capacidades de ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 7 juillet 2026 à 22:14 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 13 juillet 2026 à 21:18 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 6 juillet 2026 à 16:29 UTCidentified

   Prezado Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade com orquestração com IDScore, que está apresentando lentidão no retorno do Score de autenticação de determinados processos. Clientes que utilizam orquestração com o Trust podem enfrentar também cenários de erros em determinados processos devido a lentidão identificada. Nossa engenharia já está mobilizada para o diagnóstico e trabalhando na identificação da causa raiz para normalizar o serviço o mais breve possível. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve. Equipe Unico.

2. 6 juillet 2026 à 16:51 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno do Score de autenticação. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 6 juillet 2026 à 17:25 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 13 juillet 2026 à 21:17 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 2 juillet 2026 à 22:04 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br Em breve retornaremos com novas atualizações.

2. 2 juillet 2026 à 22:05 UTCidentified

   We are continuing to work on a fix for this issue.

3. 3 juillet 2026 à 00:04 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimento foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Estamos em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

4. 3 juillet 2026 à 01:14 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

5. 13 juillet 2026 à 20:36 UTCpostmortem

   ### **Postmortem: WhatsApp Support Channel Instability** #### **Summary** On July 2, 2026, an instability affected our WhatsApp customer support channel. During this period, automated messages from our virtual assistant \(bot\) were not being delivered to end-users. Service was fully restored after the identification and rollback of a system change within our technology partner’s environment. #### **Impact** This incident exclusively impacted customers attempting to reach support through our WhatsApp channel. While automated messages managed by the bot failed to deliver, manual messages sent by human agents continued to operate normally. Our alternative support channels, such as email and webchat, remained fully operational and were communicated as active alternatives during the instability. #### **Root Cause** The root cause was an update deployed in the messaging service managed by our technology partner. This update introduced an incompatibility within the partner's own production environment configurations. This supplier-side infrastructure failure disrupted the automated communication flow, preventing the bot from delivering messages. #### **Resolution** Our partner's technical team investigated the issue within their environment and traced the failure back to the recently deployed update. The resolution applied by the vendor consisted of performing an immediate rollback to the previous stable version of their messaging service. Once the partner completed this rollback, message delivery was successfully restored, and our support channel returned to normal operations. #### **Lessons Learned** This incident reinforced the importance of maintaining an agile contingency and communication strategy to quickly redirect our customers to alternative channels \(such as webchat and forms\) during third-party service outages. Additionally, it highlighted the need to continuously align with our key vendors regarding the requirement for more rigorous validation and testing protocols in their own environments before promoting updates that can impact our operations.

1. 26 juin 2026 à 14:10 UTCresolved

   Prezado cliente, Entre 00:17 e 10:40 de 26/06, identificamos uma instabilidade que causou falhas de acesso na plataforma SafeDoc (através do endereço seu.acesso.io) para um grupo específico de clientes. Durante esse período, alguns usuários enfrentaram dificuldades no fluxo de login, processamento e visualização de imagens e arquivos. A origem do comportamento esteve relacionada a uma atualização programada de manutenção executada na noite de 25/06, que gerou incompatibilidade na parametrização de algumas instâncias do sistema. Nossos times de Engenharia e SRE identificaram o cenário e aplicaram as correções e ajustes de configuração necessários nas instâncias afetadas. O serviço foi restabelecido e está operando normalmente. Lamentamos o ocorrido e seguimos monitorando o comportamento da plataforma para garantir a estabilidade das operações. Em caso de dúvidas, nossa equipe de CX está à disposição. Equipe Unico.

2. 3 juillet 2026 à 18:22 UTCpostmortem

   **Resumo** No dia 26 de junho de 2026, entre 00:17 e 10:40 \(horário de Brasília\), um grupo de clientes enfrentou instabilidade que afetou o acesso a alguns de nossos serviços. A falha se manifestou em erros de login, processamento e acesso a arquivos. Nossa equipe de engenharia identificou a causa e restaurou o serviço para todos os clientes afetados. **Impacto** Durante o incidente, que durou aproximadamente 10 horas e 23 minutos, 24 clientes ficaram impossibilitados de utilizar funcionalidades essenciais de nossos serviços, impactando suas operações. O acesso foi completamente restabelecido às 10:40 do dia 26 de junho de 2026. **Causa Raiz** A causa raiz do incidente foi uma falha durante um processo de atualização programada de sistema, que ocorreu na noite do dia 25 de junho. A atualização de configuração não foi aplicada corretamente em um subconjunto de servidores, fazendo com que o sistema fizesse referência a dependências de software desatualizadas e incompatíveis. Essa falha impediu a comunicação correta com serviços de armazenamento em nuvem e de autenticação, resultando nos erros observados pelos clientes. A ausência de validação automatizada pós-implantação e de alertas centralizados para este tipo de erro de configuração impediu a detecção proativa do problema. **Resolução** Assim que o incidente foi reportado na manhã do dia 26 de junho, nossa equipe de prontidão foi acionada. Foi identificado que a falha estava relacionada a uma implantação incorreta de arquivos de configuração. As equipes de engenharia aplicaram as correções necessárias em todas as instâncias afetadas, restaurando a funcionalidade completa dos serviços. Após a aplicação da correção, foi realizada uma verificação completa para garantir que todos os sistemas estivessem operando normalmente. **Lições Aprendidas** * Automação na validação: Implementações em larga escala exigem verificações automatizadas pós-implantação para garantir que todas as instâncias tenham sido atualizadas corretamente e de forma consistente. * Observabilidade centralizada: É fundamental garantir que os registros de erros de todas as aplicações sejam transmitidos para uma plataforma centralizada, permitindo a detecção rápida de anomalias, mesmo que a falha afete a própria capacidade de comunicação da aplicação. Estamos comprometidos com a confiabilidade de nossos serviços e continuaremos trabalhando para fortalecer nossos sistemas e processos.

1. 24 juin 2026 à 18:20 UTCidentified

   Prezado Cliente, Detectamos um impacto nas requisições com o fluxo do IDTrust, causando instabilidade aos clientes Mexico que utilizam essa capacidade. A nossa equipe de tecnologia está analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. 24 juin 2026 à 18:31 UTCmonitoring

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 24 juin 2026 à 18:53 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 13 juillet 2026 à 19:27 UTCpostmortem

   **Summary** On June 24, 2026, between 2:55 PM and 3:26 PM \(Brasília time\), the availability indicator for the process creation flow dropped below 95%, with a total duration of approximately 31 minutes. The incident was caused by an instability in an infrastructure provider used in the risk assessment flow, which began returning errors and latency above expected levels. The impact was concentrated on users from Mexican market clients. **Impact** Users of the process creation and authentication flows that relied on the risk assessment step received timeout errors during the period. The impact was more severe for Mexican market clients but also affected authentication flows for other clients. **Root Cause** The root cause was an instability in the infrastructure provider responsible for the risk assessment step. The provider began operating with latency well above normal and returning errors, causing requests that depended on this step to become blocked and propagate failures to the process creation and authentication flows. Internal services were unable to isolate the impact of the provider's degradation, resulting in widespread unavailability for all users passing through this step. **Resolution** The infrastructure provider stabilized on its own at 3:16 PM. The team identified a timeout configuration need during the incident and opened a correction with explicit values. The incident was closed at 3:50 PM after stability was confirmed. **Lessons Learned** The incident highlighted the need to strengthen isolation mechanisms between internal services and infrastructure providers, so that isolated instabilities do not propagate to end users. As follow-ups, the team identified improvements in the resilience of the affected flows and in the documentation of critical dependencies, aiming to reduce response time and impact in future occurrences of a similar nature.

1. 23 juin 2026 à 01:24 UTCinvestigating

   Prezado Cliente, Nossa monitoração proativa detectou um comportamento irrégulier no ID Pay e no fluxo de inboarding do ByUnico. Embora a causa exata ainda esteja sob investigigação, isso pode se manifeste como lentidão ou intermitência no serviço. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações.

2. 23 juin 2026 à 01:39 UTCidentified

   Prezado Cliente, Nossa équipe ainda está investigando a causa raiz do problema. Em breve traremos mais atualizações. Agradecemos a compreensão.

3. 23 juin 2026 à 01:53 UTCidentified

   Prezado Cliente, Information que nossa équipe identifier a causa da instabilidade e está ativamente trabalhando na aplicação da solução. Seguimos empenhados em restabeleler o serviço o mais rapidamente possível e manteremos você informado sobre a evolução. Novas atualizações serão enviadas em breve.

4. 23 juin 2026 à 02:18 UTCmonitoring

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes atracés de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à distribuer para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico !

5. 23 juin 2026 à 02:41 UTCresolved

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes atracés de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à distribuer para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico !

6. 14 juillet 2026 à 13:58 UTCpostmortem

   ** Résumé** Le 22 juin 2026, à 21h52 \(Brassilia time\), le flux d'économie de document est devenu indisponible en raison de l'épuisement d'une limite d'identificateur séquentiel dans la base de données. À partir de ce moment, toutes les opérations d'insertion de documents ont commencé à échouer, en cascade des erreurs à plusieurs services dépendants. L'incident a duré environ 86 minutes. (en milliers de dollars) **Impact** Plusieurs services critiques ont été touchés simultanément, notamment les flux d'embarquement, la création de processus, l'authentification et les paiements. Dans certains cas, la disponibilité est tombée à moins de 3 %. Les clients avaient des utilisateurs touchés par des échecs ou des retards lorsqu'ils tentaient des opérations qui dépendaient de l'enregistrement de documents. (en milliers de dollars) ** Cause de la mort** La cause fondamentale était liée au type d'identificateur 32 bits utilisé dans la table des documents, qui supporte environ 2,1 milliards de valeurs; avec la croissance naturelle du volume record au fil du temps, cette limite a été atteinte, ce qui a empêché la base de données de générer de nouveaux identifiants, de sorte que toutes les opérations d'insertion ont commencé à échouer. Comme aucune surveillance n'était configurée pour suivre la proximité de cette limite, l'épuisement s'est produit brusquement et sans avertissement préalable. (en milliers de dollars) **Résolution** L'équipe a identifié la cause profonde en environ 20 minutes. À titre d'atténuation immédiate, l'identificateur séquentiel a été reconfiguré pour utiliser la plage négative du même type de données, libérant environ 2,1 milliards de valeurs supplémentaires sans nécessiter de modification structurelle de la base de données. La solution a été validée dans des environnements inférieurs avant d'être appliquée à la production. Le service a commencé à se stabiliser peu après l'application du correctif et a été surveillé jusqu'à ce que la récupération complète soit confirmée. (en milliers de dollars) **Leçons apprises** L'incident souligne l'importance de mettre en place une surveillance pour l'utilisation d'identificateurs séquentiels dans les tableaux à volume élevé, avec des alertes précoces qui permettent de traiter l'épuisement comme une maintenance planifiée; d'adopter dès le départ des types d'identificateurs de 8 octets pour les tableaux à volume élevé d'écriture, y compris cette vérification dans les processus d'examen des schémas; et de cartographier et de documenter les dépendances critiques des services de persistance de base, afin d'évaluer l'impact et de prioriser la communication avec les utilisateurs touchés dans les prochains incidents.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 juin 2026 à 13:08 UTCinvestigating

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 19 juin 2026 à 18:34 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimentos foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Neste momento, nosso time de engenharia e operações segue em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

3. 19 juin 2026 à 19:42 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

4. 3 juillet 2026 à 20:36 UTCpostmortem

   **Sumário** No dia 19 de junho de 2026, identificamos uma instabilidade que afetou nosso canal de atendimento via WhatsApp. O incidente, que teve início aproximadamente às 09:00 e foi resolvido às 15:45 \(horário de Brasília\), impediu que nossos agentes acessassem as conversas dos clientes nessa plataforma. A causa raiz foi um problema técnico originado em um de nossos parceiros de tecnologia, que já foi corrigido. **Impacto** Durante o período do incidente, o atendimento aos clientes finais através do canal de WhatsApp foi impactado. Como alternativa, os clientes foram orientados a utilizar nossos outros canais de contato, como formulário, e-mail e webchat. As operações foram normalizadas no mesmo dia. **Causa Raiz** A investigação, conduzida em conjunto com nosso parceiro tecnológico responsável pela plataforma de gestão de conversas, revelou que a causa do incidente foi uma alteração de certificados de segurança em um sistema terceiro com o qual a plataforma se integra. Essa alteração invalidou o mecanismo de autenticação utilizado pelo serviço, impedindo a comunicação entre a plataforma de atendimento e o canal do WhatsApp. A detecção do problema foi reativa, pois a falha de autenticação não gerava alertas proativos e o ambiente de testes não utiliza os mesmos certificados do ambiente de produção, o que impediu a reprodução do erro em testes preliminares. **Resolução** Após a identificação do problema, a equipe de engenharia do nosso parceiro tecnológico atualizou os certificados de autenticação em seus sistemas para restabelecer a compatibilidade com a plataforma terceira. A correção foi aplicada e validada, normalizando o acesso dos nossos agentes às conversas e restaurando completamente o serviço de atendimento via WhatsApp às 15:45. **Lições Aprendidas** * É crucial manter uma comunicação ativa e monitorar os canais de parceiros tecnológicos para se antecipar a mudanças que possam impactar os serviços integrados. * Falhas de autenticação com serviços externos são um ponto crítico e devem possuir mecanismos de alerta específicos para permitir uma detecção e resposta mais rápidas, reduzindo o tempo de indisponibilidade. Estamos empenhados em garantir a estabilidade e a qualidade de nossos canais de atendimento e continuaremos a trabalhar em estreita colaboração com nossos parceiros para fortalecer a resiliência de nossos serviços.

1. 12 juin 2026 à 15:29 UTCidentified

   Prezado Cliente, Estamos acompanhando uma instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações.

2. 12 juin 2026 à 17:03 UTCidentified

   Prezado Cliente, Seguimos acompanhando a instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações

3. 12 juin 2026 à 18:17 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

4. 12 juin 2026 à 18:31 UTCresolved

   Prezado Cliente, Incidente resolvido. As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

1. 12 juin 2026 à 14:58 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via e-mail ou nos contatarem pelo nosso webchat como alternativa de contato sincrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 12 juin 2026 à 17:31 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas pelo nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido Atenciosamente, Equipe Unico

3. 12 juin 2026 à 18:00 UTCresolved

   Prezado Cliente, Incidente resolvido. as ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico