Störungsverlauf von Unico

1. 30. August 2026 um 02:35 UTCinvestigating

   Sehr geehrter Kunde, Um ca. 23:00 Uhr (BRT) am Freitag, den 29. August 2026, haben wir eine Instabilität festgestellt, die die Prozesserstellung in IDCloud beeinflusst. Während dieses Zeitraums können einige Anfragen fehlschlagen oder langsamer als gewöhnliche Antwortzeiten auftreten. Wir erkennen die Unannehmlichkeiten, die dies verursachen kann, und schätzen Ihr Verständnis. Ein neues Update wird in Kürze zur Verfügung gestellt. Unico Team

2. 30. August 2026 um 02:49 UTCidentified

   Unser Engineering-Team hat den Ursprung der Instabilität, die die Prozesserstellung beeinflusst, in IDCloud abgebildet. Das technische Team hat bereits mit der Anwendung von Korrekturmaßnahmen begonnen, einschließlich der Skalierung von Ressourcen in der betroffenen Schicht und der kontinuierlichen Überwachung von Schlüsselindikatoren. Die Wiederherstellung des Dienstes wird mit höchster Priorität und voller technischer Mobilisierung abgewickelt. Wir wiederholen, dass in Kürze weitere Updates verschickt werden. Unico Team

3. 30. August 2026 um 02:57 UTCmonitoring

   Sehr geehrter Kunde, Unser Engineering-Team hat die erforderlichen Korrekturmaßnahmen durchgeführt, um die Instabilität der Prozesserstellung in IDCloud zu beheben. Die Umgebung ist wieder stabil, wobei die Verfügbarkeits- und Reaktionszeitindikatoren ab 23:48 Uhr (BRT) auf ein normales Betriebsniveau gebracht wurden. Der Service ist für den normalen Gebrauch verfügbar. Zu diesem Zeitpunkt bleibt unser technisches Team unter unterstützter Überwachung und beobachtet die Umgebung genau, um eine konsistente Leistung zu gewährleisten und im Falle von Schwankungen sofort zu handeln. Wir schätzen Ihr Verständnis und wiederholen, dass weitere Updates in Kürze gesendet werden. Unico Team

4. 30. August 2026 um 03:15 UTCresolved

   Sehr geehrter Kunde, Executive Summary und Impact Zwischen 23:00 und 23:48 Uhr (BRT) am 29. August 2026 betraf ein Ausfall die Prozesserstellung in IDCloud. Während dieses Fensters erlebten einige Kunden, die diese Flüsse nutzten, Ausfälle und erhöhte Reaktionszeiten, wobei die Ausbreitung auf abhängige Reisen einschließlich Authentifizierung, Dokumentenerfassung und Benachrichtigungszustellung erfolgte. Es gab keine Kompromisse bei der Integrität oder Sicherheit der verarbeiteten Informationen und es gingen keine Daten verloren. Die Indikatoren kehrten um 23:48 Uhr (BRT) auf das normale Betriebsniveau zurück, wobei die Normalisierung sowohl in unserem Monitoring als auch auf der Kundenseite bestätigt wurde, was die Erstellung und den Abschluss des Prozesses betraf. Wurzelursache und Auflösung Der Ursprung wurde in unserer Datenschicht identifiziert: Eine interne Wartungsroutine blieb stecken, und die Anwendungsoperationen begannen, sich dahinter anzustellen, bis die verfügbare Verbindungsgrenze erschöpft war, was die Verarbeitungskapazität reduzierte. Unser Ingenieurteam beendete chirurgisch nur die festgefahrene Routine und löste sofort die Warteschlange. Verbindungen und Verarbeitungskapazität wurden vollständig wiederhergestellt, ohne Datenänderungen. Engagement und nächste Schritte Unser Engineering-Team wird sich auf drei Fronten konzentrieren: die Begrenzung der Wartezeiten für interne Wartungsroutinen, die Verhinderung, dass gleichzeitige Routinen gegen die gleiche Struktur laufen, und die Stärkung der Widerstandsfähigkeit des Dienstes gegenüber Schwankungen in der Datenschicht. Ein detaillierter Postmortem, einschließlich des vollständigen Zeitplans und eines Aktionsplans mit Fristen, wird in Kürze veröffentlicht. Wir entschuldigen uns aufrichtig für die Auswirkungen auf Ihre Operationen und bleiben über unsere Support-Kanäle verfügbar. Unico Team

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. August 2026 um 20:26 UTCidentified

   Sehr geehrter Kunde, Wir haben Auswirkungen auf einige IDCloud-Anforderungen festgestellt, die sich auf die Behavior Alert (IDTrust)-Fähigkeit und den 1:N-Fluss auswirken. Diese Instabilität kann auch Kunden in Mexiko betreffen, die diese Fähigkeit nutzen. Unser Engineering-Team wird mobilisiert, um das Problem so schnell wie möglich zu lösen. Wir werden in Kürze neue Updates bereitstellen.

2. 10. August 2026 um 20:29 UTCmonitoring

   Unser Engineering-Team hat die notwendigen Maßnahmen identifiziert und implementiert, um die Instabilität in den betroffenen IDCloud-Flow-Funktionen zu beheben. Zu diesem Zeitpunkt führt das technische Team eine detaillierte Analyse unserer Datenschicht durch und überwacht weiterhin die Umwelt. Wir wiederholen, dass in Kürze weitere Updates verschickt werden.

3. 10. August 2026 um 21:01 UTCresolved

   Executive Summary und Impact Gegen 17:08 Uhr erkannte eine automatisierte Warnung einen Verfügbarkeitsrückgang im Gesichtserkennungsdienst (1:N-Flow), der den Vorfall auslöste. Das Problem eskalierte schnell und begann, den Verhaltenswarnungsdienst und anschließend den Prozesserstellungsfluss aufgrund von kaskadierenden Timeouts zwischen diesen Diensten zu beeinflussen. Die Auswirkungen betrafen eine Untergruppe von Kunden, die diese Fähigkeiten nutzen. Die Situation wurde um 17:22 Uhr als stabilisiert gemeldet, wobei die Metriken auf ein normales Niveau zurückkehrten. Wurzelursache und Auflösung Die Ursache war ein Traffic-Spike, der durch eine interne Workload erzeugt wurde, die eine hohe Anzahl von Gesichtserkennungsanforderungen direkt in die biometrische Pipeline schickte und die vom normalen Client-Traffic verwendete Randschicht umging. Dieses zusätzliche Volumen sättigte die Kapazität der Datenbank, die den Gesichtserkennungsdienst unterstützt. Die Sättigung verursachte Timeouts in diesem Dienst, der zum biometrischen Motor-Orchestrierungsdienst, dann zum Verhaltenswarnungsdienst und schließlich zum Prozesserstellungsfluss unter Verwendung dieser Fähigkeiten kaskadierte. Um das Problem zu beheben, stoppte das Team die für den Spike verantwortliche Arbeitslast und erhöhte die Kapazität der betroffenen Datenbank. Diese Aktionen entschärften das Problem, wobei das Fehlervolumen auf nahezu Null-Niveaus zurückkehrte. Engagement und nächste Schritte Ein Folgeartikel wurde geöffnet, um die Geschwindigkeitsbegrenzung für die Art der internen Arbeitsbelastung, die den Spike verursacht hat, als vorbeugende Maßnahme gegen ein Wiederauftreten zu implementieren. Die Kapazitätserhöhung für die betroffene Datenbank wurde bereits während des Vorfalls selbst durchgeführt.

4. 25. August 2026 um 13:05 UTCpostmortem

   **Zusammenfassung** Am 10. August 2026, zwischen 17:08 Uhr und 17:27 Uhr \(Brasília-Zeit\), fiel der Verfügbarkeitsindikator für den 1:N-Gesichtserkennungsfluss unter 95%, mit einer Gesamtwirkung von etwa 19 Minuten. Der Vorfall wurde durch die Sättigung der Vektorsuchdatenbank verursacht, die von der biometrischen Engine verwendet wurde, was auf ein unerwartetes Verhalten im Warteschlangenverbrauchsmechanismus zurückzuführen ist, der ein 2,36-mal höheres Anrufvolumen als konfiguriert erzeugte. Die Überlastung erreichte die maximale Skalierungsgrenze der Datenbank, was zu kaskadierenden Timeouts bei mehreren abhängigen Diensten führte und 55 Client-Benutzer während des Zeitraums mit Fehlern behaftete. **Auswirkungen** Benutzer der Gesichtserkennung, Authentifizierung und Prozesserstellung fließen von mehreren Clients, die während des Zeitraums Fehler und Timeouts erlebt haben. Die Datenbanksättigung kaskadierte durch biometrische Orchestrierung, Engine und Prozesserstellung. Die Minderung erfolgte durch Deaktivierung eines internen Dienstes und Erhöhung der maximalen Skalierungsgrenze der Datenbank, wodurch der Dienst um 17:27 Uhr stabilisiert wurde. **Wurzelursache** Ursache war eine Kombination von Faktoren im Zusammenhang mit dem Serviceverhalten und der Kapazität der beteiligten Infrastruktur. Der Dienst wurde mit einem Limit von 2 Anfragen pro Sekunde konfiguriert, aber der Warteschlangenverbrauchsmechanismus verhielt sich unerwartet: Nachrichten, deren Verarbeitung die Bestätigungsfrist überschritten hatte, wurden von der Warteschlange erneut zugestellt, ohne die ursprüngliche Ausführung zu stornieren - 938 Arbeitselemente wurden in 2.217 effektive Anrufe umgewandelt (~8.4 RPS). Dieser verstärkte Datenverkehr erreichte die Datenbank, ohne die Kantenschutzschicht zu durchlaufen, was normalerweise das Anforderungsvolumen einschränken würde, da der in diesem Fluss verwendete Netzwerkpfad diese Kontrollen nicht durchlaufen hat. Die Datenbank, die bereits in der Nähe ihrer maximalen Skalierungsgrenze arbeitete, konnte die zusätzliche Last nicht absorbieren - ihre CPU erreichte 88% bei der Skalierung bis zur konfigurierten Decke von 100 Knoten - und die Abfragelatenz sprang von ~ 3 Sekunden auf ~ 18,75 Sekunden bei p90, was Timeouts über die gesamte Kette abhängiger Dienste verteilte. **Resolution** Das Team identifizierte den betreffenden Prozess als Quelle der Last innerhalb weniger Minuten nach dem Alarm. Der Prozess wurde deaktiviert und die maximale Skalierungsgrenze der Datenbank wurde von 100 auf 150 Knoten erhöht. Mit diesen beiden Aktionen stabilisierte sich der Dienst um 17:27 Uhr. **Lektionen gelernt** Der Vorfall zeigte, dass die Preisbegrenzung, die nur auf der Seite der Nachrichtenveröffentlichung angewendet wird, unzureichend ist, wenn der Verbraucher das Volumen durch Nachlieferung verstärken kann. Raten- und Gleichzeitigkeitskontrollen müssen auch auf der Konsumseite existieren. Darüber hinaus stellen interne Dienste, die über Pfade, die Kantenschutz umgehen, auf kritische Komponenten zugreifen, ein strukturelles Risiko dar – jeder interne Client kann eine unkontrollierte Belastung der gemeinsamen Infrastruktur erzeugen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. Juli 2026 um 12:42 UTCinvestigating

   Prezados clientes, 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. No 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 corrigir a exibição na interface e restabelecer o histórico no painel o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos informados sobre o progresso. Atenciosamente,

2. 31. Juli 2026 um 13:08 UTCidentified

   Prezados clientes, 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 técnica. No momento, os engenheiros já estão subindo a correção para restabelecer a exibição correta de todos os envios na interface do remetente. Lembramos que o processamento, envio e assinatura dos documentos continuam operando normalmente. Volataremos com uma nova atualização assim que a correção for concluída e entrarmos na fase de monitoramento. Atenciosamente,

3. 31. Juli 2026 um 13:20 UTCmonitoring

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

4. 31. Juli 2026 um 14:06 UTCresolved

   Prezados clientes, Informamos que o incidente relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após a aplicação da correção e o período de monitoramento, 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 durante o processo. Atenciosamente,

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. Juli 2026 um 14:04 UTCresolved

   Executive Summary & Impact Wir möchten Sie darüber informieren, dass der Vorfall, der den ID Cloud Webhook-Benachrichtigungsdienst vorübergehend betrifft, behoben wurde. Wirkungszeit: Von 08:32 bis 10:05. Plattformauswirkungen: Die Instabilität war strikt auf die Webhook-Benachrichtigungszustellung beschränkt, was zu einer Verzögerung bei der Nachrichtenverteilung führte. Es gab keine Verschlechterung der Hauptplattform, keine Ausfälle in der Liveness-Engine und keinen Datenverlust. Customer Impact: Das Problem betraf einen kleinen Teil der Kunden. Kunden, die einen GET-Umfragefluss als Notfall (Fallback) implementiert haben, erlebten keine Ausfallzeiten oder operative Auswirkungen. Wurzelursache & Auflösung Wurzelursache: Die Instabilität wurde durch ein Feature-Update in der Umgebung ausgelöst. Eine vorübergehende Diskrepanz bei den Zugriffsberechtigungen zwischen der Aufgabenwarteschlange und der Zielroute führte dazu, dass Anfragen abgelehnt wurden, was zu einem vorübergehenden Rückstau von Benachrichtigungen führte. Lösliche Wirkung: Das technische Team hat die Verkehrsumleitung in die neue Umgebung abgeschlossen, die ordnungsgemäße Kommunikation zwischen den Komponenten wiederhergestellt und den Backlog von Webhooks freigegeben. Die Verarbeitung hat sich wieder normalisiert und die Versandwarteschlange wurde vollständig gelöscht. Engagement & nächste Schritte Die Stabilität unserer Dienstleistungen hat höchste Priorität. Um absolute Transparenz zu gewährleisten und Wiederholungen zu verhindern, wird sich unser Engineering-Team auf folgende Fronten konzentrieren: Detailliertes Postmortem: Ein umfassender Bericht mit einer eingehenden Ursachenanalyse und einem präventiven Aktionsplan wird erstellt. Verbesserungen der Beobachtbarkeit: Wir werden die Überwachungsmetriken anpassen, um eine bessere Sichtbarkeit von Kommunikationsfehlern zwischen Diensten während Übergangsszenarien zu gewährleisten. Wir entschuldigen uns aufrichtig für die Unannehmlichkeiten und bleiben für weitere Klarstellungen zur Verfügung. Ehrlich gesagt, Unico Team

2. 7. August 2026 um 13:08 UTCpostmortem

   **Zusammenfassung** Am 29. Juli 2026, zwischen 8:32 Uhr und 10:05 Uhr (Brasilia-Zeit), wurde der Webhook-Lieferservice für etwa 1 Stunde und 33 Minuten abgebaut. Der Vorfall wurde durch eine geplante Infrastrukturmigration verursacht, die einen vorübergehenden Inkompatibilitätszustand verursachte: Nachdem interne Routen auf den neuen Cluster umgestellt wurden, begann der Webhook-Dienst, Authentifizierungstoken aus dem neuen Cluster zu generieren, aber die Lieferungen wurden immer noch an den alten Cluster weitergeleitet - der die Token mit einem Autorisierungsfehler ablehnte. Verlorene Ereignisse wurden bei Bedarf wiederaufbereitet. **Auswirkungen** Mehrere Produkte waren gleichzeitig betroffen – einschließlich Authentifizierung, Zahlungen und Onboarding-Flows. Benutzer von Kunden, die sich ausschließlich auf Webhook-Benachrichtigungen verließen, um ihre Geschäftsströme fortzusetzen, erlebten in diesem Zeitraum Betriebsunterbrechungen. Kunden, die aktives Polling als Fallback-Mechanismus implementiert hatten, hatten geringere Auswirkungen. **Wurzelursache** Die Hauptursache wurde in der Migrationsplanung identifiziert: Das Verfahren bildete die verkettete Abhängigkeit des Webhook-Flows nicht ab, wobei die interne Route eine asynchrone Aufgabe erzeugt, die wiederum die öffentliche Route zur Lieferung aufruft. Durch die Migration der internen Routen und der öffentlichen Routen in separaten Schritten wurde ein Inkompatibilitätsfenster erstellt, in dem die von dem neuen Cluster generierten Token durch die Autorisierungsrichtlinie des alten Clusters abgelehnt wurden, die speziell die vorherige Dienstkontokennung validierte. Dieses Szenario wurde während der Risikobewertung der Änderung nicht identifiziert, und keiner der vorhandenen Servicequalitätsindikatoren deckte die asynchrone Bereitstellungsschicht ab, in der der Fehler eintrat. **Resolution** Das Team identifizierte die Token-Inkompatibilität als Quelle der Fehler und schloss die Migration der öffentlichen Routen zu dem neuen Cluster ab, wodurch die Divergenz beseitigt wurde. Ab diesem Zeitpunkt begannen die ausstehenden Lieferungen in der Warteschlange mit der normalen Verarbeitung. Der Aufprall endete um 10:05 Uhr und der Verkehr auf dem alten Cluster erreichte um 10:32 Uhr Null. **Lektionen gelernt** Der Vorfall zeigte, dass Migrationen mit verketteten asynchronen Lieferströmen erfordern, dass alle an der Kette beteiligten Routen - intern und öffentlich - koordiniert migriert werden, ohne dass es zu Inkompatibilitätsfenstern zwischen Clustern kommt. Der verwendete schrittweise Ansatz, der für die meisten Migrationen geeignet ist, schuf hier eine verlängerte Ausfallzeit, die mit einem atomaren Übergang oder einem viel kürzeren Übergangsfenster hätte vermieden werden können. Darüber hinaus war der Mangel an Beobachtbarkeit an der asynchronen Übertragungsschicht der Grund, warum der Vorfall nicht intern erkannt wurde - vorhandene Indikatoren gemessen nur Ereignisakzeptanz, nicht tatsächliche Lieferung. Die Erstellung dedizierter Warnmeldungen für Fehler und Rückstand auf dieser Ebene ist die dringendste Verbesserung der Überwachung.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juli 2026 um 21:47 UTCinvestigating

   Sehr geehrter Kunde, Wir untersuchen derzeit eine Instabilität in unseren Webhooks, die die Latenz bei der Datenbereitstellung beeinflusst. Unser Engineering-Team arbeitet aktiv daran, das Problem so schnell wie möglich zu lösen. Wir werden in Kürze weitere Updates bereitstellen.

2. 24. Juli 2026 um 21:53 UTCmonitoring

   Sehr geehrter Kunde, Unser Engineering-Team hat die notwendigen Maßnahmen identifiziert und umgesetzt, um die Webhook-Instabilität zu beheben, die sich auf die Latenz der Datenbereitstellung auswirkt. Zu diesem Zeitpunkt führt das technische Team eine detaillierte Analyse unserer Datenschicht durch und überwacht weiterhin die Umwelt. Wir wiederholen, dass in Kürze weitere Updates verschickt werden.

3. 24. Juli 2026 um 22:18 UTCresolved

   Executive Summary und Impact Ab 18:05 Uhr (Brasília-Zeit) trat eine Instabilität im Webhook-Service auf, die zu einem Ausfall der Ereignisverarbeitung und Benachrichtigungszustellung für betroffene Operationen in diesem Zeitraum führte. Wurzelursache und Auflösung Der Vorfall wurde durch ein Problem mit einem gemeinsamen Dienstkonto verursacht, das über mehrere Dienste hinweg verwendet wurde, was zu Authentifizierungsfehlern führte. Nach der Identifizierung der Ursache stellte das Engineering-Team die erforderlichen Anmeldeinformationen und die Konfiguration wieder her. Der Normalbetrieb wurde um 6:29 Uhr (BRT) vollständig wiederhergestellt. Engagement und nächste Schritte Im Rahmen der kontinuierlichen Verbesserung und Risikominderung wird das Engineering-Team die Ressourcenabhängigkeiten und das Zugriffsmanagement dienstleistungsübergreifend überprüfen. Dies wird ähnliche Konfigurationsprobleme bei zukünftigen Infrastrukturanpassungen verhindern.

4. 3. August 2026 um 20:00 UTCpostmortem

   **Zusammenfassung** Am 24. Juli 2026, zwischen 18:05 Uhr und 18:29 Uhr \(Brasília Zeit\), war der Webhook-Erstellungs- und Lieferservice für etwa 24 Minuten nicht verfügbar. Der Vorfall wurde durch den Verlust des Zugangs zu einem Infrastrukturdienstkonto während eines Ressourcenstilllegungsprozesses verursacht, der mit einer Clustermigration verbunden war, die Tage zuvor durchgeführt wurde. Das betroffene Konto wurde von mehreren Diensten geteilt, ohne dass diese Abhängigkeit dokumentiert wurde, was dazu führte, dass der Webhook-Dienst seine Authentifizierungsfähigkeit verlor und das Erstellen und Bereitstellen von Ereignissen beendete. **Auswirkungen** Die Erstellung und Lieferung von Webhook-Events wurde in diesem Zeitraum unterbrochen und betraf 18 Client-Benutzer mit mehr als 1.550 registrierten Fehlern. Die Auswirkungen gingen auf andere Dienste über, die vom gleichen Authentifizierungsfluss abhängig waren, was zu einer gleichzeitigen Verschlechterung der verschiedenen Plattformfunktionen führte. **Wurzelursache** Die Ursache wurde in der Service Dependency Konfiguration identifiziert. Diese dienstübergreifende Abhängigkeit wurde weder dokumentiert noch in einem Abhängigkeits-Mapping sichtbar. Als der Dekommissionierungsprozess das Konto als Teil der Ressourcenbereinigung des ursprünglichen Dienstes entfernte, gab es keine automatisierte Validierung, um zu überprüfen, ob das Konto noch von anderen aktiven Diensten verwendet wurde. Das Fehlen dieser Sicherheit hielt die Abhängigkeit verborgen, bis ihre Entfernung zu weit verbreiteten Authentifizierungsfehlern führte. **Resolution** Das Team identifizierte das instabile Dienstkonto schnell als Quelle für die Authentifizierungsfehler. Das Konto wurde manuell angepasst und auf den Cluster angewendet, wodurch der Dienst um 18:29 Uhr wiederhergestellt wurde. Die Gesamtaufpralldauer betrug ca. 24 Minuten. **Lektionen gelernt** Der Vorfall enthüllte die Risiken von Legacy-Konfigurationen, die versteckte Abhängigkeiten zwischen Diensten erzeugen: Eine einzige Ressourcenänderung während der geplanten Wartung reichte aus, um mehrere Dienste gleichzeitig zu unterbrechen. Die Stilllegung von Infrastrukturressourcen muss vor jeder Änderung eine automatisierte Abhängigkeitsvalidierung umfassen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. Juli 2026 um 16:39 UTCidentified

   Sehr geehrter Kunde, Wir untersuchen eine Instabilität in den IDCloud-Funktionalitäten, die sich auf die Authentifizierungsströme in der Prozessreise auswirkt, insbesondere auf die Web Journey (früher ByUnico). Unser Engineering-Team wird mobilisiert, um das Problem so schnell wie möglich zu lösen. Wir werden in Kürze weitere Updates bereitstellen.

2. 21. Juli 2026 um 16:49 UTCmonitoring

   Sehr geehrter Kunde, Unser Engineering-Team hat die notwendigen Maßnahmen identifiziert und implementiert, um die Instabilität in den betroffenen IDCloud-Flow-Funktionen zu beheben. Zu diesem Zeitpunkt führt das technische Team eine detaillierte Analyse unserer Datenschicht durch und überwacht weiterhin die Umwelt. Wir wiederholen, dass in Kürze weitere Updates verschickt werden.

3. 21. Juli 2026 um 18:02 UTCresolved

   Executive Summary und Impact Ab ca. 12:44 Uhr (Brasília-Zeit) am 21. Juli 2026 erlebte ein Teil der Benutzer in der reduzierten Onboarding-Reise ein langsameres Laden der ersten Bildschirme im Fluss. Die Auswirkungen wurden in allen Umgebungen beobachtet, in denen diese Reise genutzt wird, was sich auf die wahrgenommene Geschwindigkeit und in geringerem Maße auf die Fähigkeit der Benutzer auswirkt, den Prozess während dieses Zeitraums abzuschließen. Wurzelursache und Auflösung Die Untersuchung läuft, um die endgültige Ursache des Vorfalls zu bestätigen. Es gab keine Auswirkungen auf Server, Netzwerk oder Infrastruktur - das Problem wurde bestätigt, dass es von der Bildschirmerfahrung auf dem Gerät des Benutzers isoliert war. Als Containment-Maßnahme hat das zuständige Team um 1:39 Uhr (BRT) eine vorbeugende Anpassung vorgenommen und die Ladezeiten innerhalb weniger Minuten wieder normalisiert. Die Analyse zur Validierung und Bestätigung der Ursache wird noch vom technischen Team durchgeführt. Engagement und nächste Schritte Im Rahmen der kontinuierlichen Verbesserung der Incident-Response-Prozesse verpflichtet sich das Team, den automatischen Eskalationsfluss für verantwortliche Teams zu verbessern und die Aktivierung ab dem Zeitpunkt der Eröffnung eines Incidents noch direkter und effektiver zu gestalten. Darüber hinaus wird die Überwachung der Ladegeschwindigkeit während der Einführung neuer Änderungen an dieser Reise verstärkt, mit dem Ziel, mögliche Regressionen noch schneller zu identifizieren und zu korrigieren und die Auswirkungen auf die Benutzer in ähnlichen Situationen zu minimieren.

4. 3. August 2026 um 14:01 UTCpostmortem

   **Zusammenfassung** Am 21. Juli 2026, zwischen 12:44 Uhr und 13:43 Uhr \(Brasília-Zeit\), verschlechterten sich die Seitenladeleistungsindikatoren für die reduzierte Reise stark, wobei die durchschnittliche Ladezeit von ~ 4,8 s auf ~ 8,9 s und der p95 31,5 Sekunden erreichte. Der Vorfall wurde durch eine Tarifbegrenzung der Cloud-Infrastruktur auf Verbindungen des Anbieters verursacht, die das Laden von Frontend-Assets verhinderte. **Auswirkungen** Benutzer von 32 Kunden erlebten extrem langsame Seitenladungen oder vollständige Ladefehler, wobei etwa 94 Reisefehler aufgezeichnet wurden. "Initialisierungs-Timeout" -Fehler - ausgelöst, wenn die Anwendung nicht innerhalb von 30 Sekunden gemountet wird - erreichten während des Zeitraums etwa 23 Tausend Ereignisse. **Wurzelursache** Die Ursache wurde in der Netzwerkschicht der Infrastruktur identifiziert: Der CDN-Anbieter konsolidiert den Datenverkehr über eine begrenzte Anzahl von ausgehenden IP-Adressen. Ein Anstieg der neuen TCP-Verbindungen und TLS-Handshakes, die von diesen IPs stammen, löste die automatischen Netzwerkschicht-Verteidigungsmechanismen der Cloud-Infrastruktur aus, die bereits vor der HTTP-Verarbeitung ratenbegrenzende Verbindungen begannen. Da diese Fehler auf der Netzwerkschicht vor der HTTP-Verarbeitung auftraten, erschienen sie nicht in Standard-Anfrageprotokollen, was das Problem für die konventionelle Überwachung unsichtbar macht und die Diagnose erheblich erschwert. **Resolution** Die Auswirkungen hörten mit der natürlichen Wiederherstellung der von der Cloud-Infrastruktur angewandten Ratenbegrenzung auf. Die Deaktivierung einer Komponente, die ursprünglich als mögliche Ursache gekennzeichnet war, fiel zeitlich mit der Wiederherstellung zusammen, wurde jedoch später als nicht mit dem Vorfall verbunden bestätigt. Konfigurationskorrekturen, die HTTP Keep-Alive mit einem verlängerten Timeout ermöglichen und eine Genehmigungsregel für CDN-IPs auf der Kantenschutzschicht hinzufügen, wurden von den Supportteams der beteiligten Anbieter als Folgeelemente identifiziert. **Lektionen gelernt** Der Vorfall hob hervor, dass Ausfälle auf der Netzwerkschicht zwischen dem CDN und der Cloud-Infrastruktur für die Standardanwendungsüberwachung unsichtbar sind und einen signifikanten blinden Fleck erzeugen. Als Folgeelemente identifizierte das Team die Notwendigkeit, die von den Anbietern empfohlenen Konfigurationskorrekturen zu implementieren und die Beobachtbarkeit auf der Asset Delivery-Schicht zu erweitern, um diese Art von Degradation proaktiv zu erkennen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. Juli 2026 um 14:39 UTCidentified

   Sehr geehrter Kunde, Wir untersuchen eine Instabilität unserer IDCloud-Fähigkeiten, die sich auf die Prozesserstellung und den Ablauf der Prozessdetails auswirkt. Unser Engineering-Team wird mobilisiert, um das Problem so schnell wie möglich zu lösen. Wir werden in Kürze weitere Updates bereitstellen.

2. 21. Juli 2026 um 14:46 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

3. 21. Juli 2026 um 14:50 UTCmonitoring

   Sehr geehrter Kunde, Unser Engineering-Team hat die notwendigen Maßnahmen identifiziert und implementiert, um die Instabilität in den betroffenen IDCloud-Flow-Funktionen zu beheben. Zu diesem Zeitpunkt führt das technische Team eine detaillierte Analyse unserer Datenschicht durch und überwacht weiterhin die Umwelt. Wir wiederholen, dass in Kürze weitere Updates verschickt werden.

4. 21. Juli 2026 um 16:00 UTCresolved

   Executive Summary und Impact Am 21. Juli 2026, gegen 11:17 Uhr BRT, wurde ein Rückgang der Verfügbarkeit in den IDCloud-Erstellungsprozess- und Prozessabfrageströmen festgestellt. Während des Impact-Fensters erlebte ein Teil der Kunden eine erhöhte Latenz und Ausfälle (Timeouts) in diesen Operationen, die sich durch die Kette abhängiger Dienste ausbreiteten. Der effektive Schlag wurde in einem Fenster von ca. 23 Minuten konzentriert. In Spitzenzeiten lagen die Fehler- und Latenzindikatoren über dem normalen Betriebsniveau. Wurzelursache und Auflösung Die Untersuchung wies auf die Verschlechterung einer Lesedatenbank (Replica) hin, die diese Fähigkeiten als Ursprung unterstützt. Diese Datenbank zeigte eine erhöhte Lade- und Abfrageausführungszeit, wobei interne Konflikte die Verarbeitung blockierten und Leseanforderungen gesichert wurden. Infolgedessen begannen die oben genannten Dienste, Timeouts zu akkumulieren und Schutzmechanismen (Leistungsschalter) auszulösen, was den kaskadierenden Effekt der Kunden erzeugte. Engagement und nächste Schritte Unico behandelt diesen Vorfall mit einem detaillierten Postmortem, das bereits entworfen wird, und wird eine Post-Incident-Review-Sitzung (PiR) abhalten, um präventive Maßnahmen zu konsolidieren. Zu den Follow-ups, die bereits während der Antwort angesprochen wurden, gehören die Vorbereitung von Diagnoseroutinen und Abfragen, um die Identifizierung von Streitigkeiten in dieser Datenbankschicht zu beschleunigen, und eine verbesserte Beobachtbarkeit über die beteiligten Datenbanken. Die detaillierten präventiven Maßnahmen werden in der Postmortem geteilt werden. Wir bekräftigen unser Engagement für die Stabilität und Zuverlässigkeit der Plattform und entschuldigen uns für die Unannehmlichkeiten, die während der Zeit der Instabilität verursacht wurden. Unico Team.

5. 28. Juli 2026 um 12:10 UTCpostmortem

   **Zusammenfassung** Am 21. Juli 2026, zwischen 11:41 und 11:43 Uhr (Brasília-Zeit), wurde der Prozesserstellungsfluss nicht verfügbar, wobei die Hauptdienstfehlerrate 42% und die Latenzzeit von p99 bei 15,75 Sekunden erreichte. Der Vorfall wurde durch Sättigung in der Biometrie-Datenbank-Lese-Replik verursacht: Der Datenbank-Speicherpool war nicht mehr in der Lage, den am häufigsten aufgerufenen Datensatz zu bedienen, was dazu führte, dass normalerweise schnelle Abfragen auf Festplattenlesungen zurückgreifen, was eine sich selbst verstärkende Spirale von akkumulierten Sitzungen und zunehmender Latenz erzeugte. **Auswirkungen** Benutzer der Prozesserstellung, Authentifizierung und Zahlungsströme über mehrere Clients hinweg haben während des Zeitraums Fehler und Timeouts erhalten. Die primäre Datenbank blieb während des gesamten Vorfalls intakt - der Fehler wurde auf die gelesene Replik isoliert. **Wurzelursache** Die Ursache war die Sättigung: Abfragen, die im Authentifizierungsfluss verwendet wurden, führten aufgrund fehlender Indizes umfangreiche Scans an kritischen Tabellen durch. Unter normalen Bedingungen wurde dieses Verhalten von der Datenbankinfrastruktur toleriert. Als die Speicherkapazität ihre Grenze erreichte und die am häufigsten aufgerufenen Daten nicht mehr im Cache speichern konnte, begann jedes Lesen, Daten von der Festplatte abzurufen, was die Kosten für jede Abfrage exponentiell erhöhte. Dieser abrupte Kollapseffekt - bei dem die allmähliche Degradation einem weit verbreiteten Fehler Platz macht - wurde selbstverstärkend, da sich die Sitzungen auf Antworten akkumulierten und der interne Ressourcenkonflikt in der Datenbank zunahm. Darüber hinaus wurde der gesamte Leseverkehr für den kritischen Fluss auf eine einzelne Replik ohne Verteilung oder alternative Route konzentriert, wodurch jegliche Widerstandsfähigkeit gegenüber dieser Art von Degradation eliminiert wurde. **Resolution** Die Datenbank erholte sich auf natürliche Weise, als die angesammelten Sitzungen abgelassen wurden, was keinen manuellen Eingriff erforderte. Das Team eskalierte zum Datenbankteam und überwachte die Servicestabilisierung. Der Vorfall wurde abgeschlossen, nachdem bestätigt wurde, dass der normale Betrieb wiederhergestellt wurde. **Lektionen gelernt** Der Vorfall offenbarte strukturelle Lücken in der Datenbankschicht: fehlende Indizes zu kritischen Abfragen und Konzentration des gesamten Leseverkehrs auf einer einzelnen Replik ohne alternative Route. Als Follow-ups priorisierte das Team die Erstellung der fehlenden Indizes, die Verteilung des Leseverkehrs auf Replikate und die Erstellung diagnostischer Runbooks, um die Reaktion bei zukünftigen Vorfällen ähnlicher Art zu beschleunigen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Juli 2026 um 12:33 UTCidentified

   Sehr geehrter Kunde, Wir haben eine Instabilität in einigen unserer IDCloud-Fähigkeiten festgestellt, die sich auf den GetSelfie-, Prozesserstellungs- und Prozessdetailfluss für die Web Journey (früher ByUnico) auswirken. Die API Journey (ByClient)-Flows waren nicht betroffen. Unser Engineering-Team wird mobilisiert, um das Problem so schnell wie möglich zu lösen. Wir werden in Kürze weitere Updates veröffentlichen.

2. 20. Juli 2026 um 12:35 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

3. 20. Juli 2026 um 12:39 UTCmonitoring

   Sehr geehrter Kunde, Unser Engineering-Team hat die notwendigen Maßnahmen identifiziert und implementiert, um die Instabilität in den betroffenen IDCloud-Flow-Funktionen zu beheben. Zu diesem Zeitpunkt führt das technische Team eine detaillierte Analyse unserer Datenschicht durch und überwacht weiterhin die Umwelt. Wir wiederholen, dass in Kürze weitere Updates verschickt werden.

4. 20. Juli 2026 um 13:22 UTCresolved

   Executive Summary und Impact Wir haben eine Instabilität festgestellt, die sich auf den Prozesserfassungs- und Visualisierungsfluss sowie die Authentifizierung für die Web Journey auswirkt, mit Auswirkungen zwischen 09:07 und 09:21 (BRT). Die Auswirkungen erreichten einen Teil der Clients, die diesen Flow nutzten; die API Journey war nicht betroffen. Wurzelursache und Auflösung Die Ursache ist mit einer Konfigurationsänderung in der Produktion verbunden, die zu einer erhöhten Belastung einer internen Datenbankkomponente führte. Diese erhöhte Last erhöhte Latenz und Fehler in einer Integrationsschicht, was wiederum einen Schutzmechanismus auslöste und die Web Journey-Flows vorübergehend unterbrach. Das Engineering-Team rollte die Konfigurationsänderung zurück, um das Problem zu mildern, und die Situation normalisierte sich kurz danach. Engagement und nächste Schritte Das Engineering-Team überwacht weiterhin die Umgebung nach dem Rollback der vorgenommenen Änderungen. Ein detailliertes Postmortem wird in den kommenden Tagen von unserem Team geteilt. Wir entschuldigen uns für die Unannehmlichkeiten. Unico Team!

5. 4. August 2026 um 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.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 14:02 UTCinvestigating

   Sehr geehrter Kunde, Wir untersuchen eine Instabilität in unserem Authentifizierungssystem für die Unico People-Portale und bewerten auch Probleme in unserem Messaging-Service, die IDCloud-Kunden betreffen. Unser Engineering-Team wird mobilisiert, um das Problem so schnell wie möglich zu lösen. Wir werden in Kürze Updates bereitstellen.

2. 16. Juli 2026 um 14:08 UTCmonitoring

   Sehr geehrter Kunde, Unser Team identifizierte das Problem und ergriff Maßnahmen, um den Vorfall zu beheben. Wir erlebten eine Instabilität in unserem Authentifizierungssystem für die Unico People-Portale sowie Probleme in unserem Messaging-Service, die Kunden im IDCloud-Flow für SMS und E-Mail-Zustellung betreffen. Unser Ingenieurteam bleibt mobilisiert und überwacht die Umgebung, um sicherzustellen, dass sie weiterhin ordnungsgemäß funktioniert.

3. 16. Juli 2026 um 15:28 UTCresolved

   Executive Summary und Impact Um 10:51 Uhr am 16.07.2026 wurde ein Problem im Authentifizierungsdienst auf dem Unico People-Zulassungsportal und im Messaging identifiziert, das die Zustellung von SMS- und E-Mail-Links an Unico People und IDCloud-Clients sowie die B2C-Client-Authentifizierung auf dem Unico People-Zulassungsportal betraf. Die Auswirkungen beschränkten sich auf diese beiden Strömungen und hatten keinen Einfluss auf den zentralen kritischen Weg des Produkts. Der Vorfall dauerte etwa 30 Minuten bis zur vollständigen Auflösung. Wurzelursache und Auflösung Die Ursache wurde als Speicherdruck auf einem Knoten des Messaging-Clusters identifiziert, der einen kritischen Festplattenschwellenwert erreichte und die Verarbeitung von Warteschlangen, die für die Übermittlung und Authentifizierung von Nachrichten verantwortlich sind, verschlechterte. Das Engineering-Team erhöhte die Speicherkapazität des Clusters um ca. 10:59 Uhr, wodurch sich Warteschlangen und Überwachungsindikatoren innerhalb von Minuten normalisierten. Die Umgebung wurde überwacht, bis die vollständige Genesung bestätigt wurde, und der Vorfall wurde um 11:20 Uhr geschlossen. Engagement und nächste Schritte Das Engineering-Team wird die Warnskalations- und Priorisierungskriterien für diese Art von Verschlechterung überprüfen, da die Warnmeldungen das Problem korrekt identifiziert haben, der automatische Eskalationsfluss an das zuständige Team jedoch verbessert werden kann. Ein detailliertes Postmortem wird vorbereitet und wird in den kommenden Tagen geteilt.

4. 3. August 2026 um 12:14 UTCpostmortem

   **Zusammenfassung** Am 16. Juli 2026, zwischen 10:12 Uhr und 11:10 Uhr (Brasília-Zeit), wurde der Messaging- und Authentifizierungsdienst für etwa 58 Minuten abgebaut. Die Ursache war die Festplattensättigung auf einem der Knoten in der Nachrichtenwarteschlange, die nach Erreichen des konfigurierten Limits automatisch alle Publisher blockierte, was zu einem Rückstand von bis zu 33.000 Nachrichten in der Warteschlange führte. Die Auswirkungen betrafen die Bereitstellung von Authentifizierungslinks per SMS und E-Mail sowie den Authentifizierungsfluss für Endbenutzer auf dem Unico People-Eintrittsportal. **Auswirkungen** Benutzer, die auf Authentifizierungslinks per SMS oder E-Mail warten, haben sie während des Zeitraums nicht erhalten. Endbenutzer eines People-Management-Produkts, die versuchen, sich auf dem Zulassungsportal zu authentifizieren, konnten ebenfalls nicht auf den Dienst zugreifen. Der Aufprall wurde eingedämmt, nachdem die Scheibe des Clusters erweitert wurde. **Wurzelursache** Die Hauptursache wurde im Nachrichtenverarbeitungsfluss identifiziert: übermäßig große Nutzlasten, die von einer Auditing-Komponente generiert wurden, die unnötige Daten enthielt, überschritten die vom Nachrichtenwarteschlange-Cluster akzeptierte Größenbegrenzung. Da sie bei jedem Versuch deterministisch abgelehnt wurden, wurden diese Nachrichten nach Ausschöpfung aller Versuche in Warteschlangen mit toten Buchstaben geroutet. Diese Warteschlangen hatten keinen Ablauf oder automatische Bereinigungsrichtlinien, was dazu führte, dass sich Nachrichten auf unbestimmte Zeit ansammelten und schrittweise den Speicherplatz des Clusters verbrauchten. **Resolution** Die Festplatte des Clusters wurde auf 500 GB pro Knoten erweitert, was die Warteschlangen und Clustermetriken sofort normalisierte. Der Service ging um 11:10 Uhr wieder normal. Die strukturelle Ursache - die unbestimmte Akkumulation in den Warteschlangen mit toten Buchstaben - bleibt als Folgeelement bestehen. **Lektionen gelernt** Der Vorfall bekräftigt, dass die Behandlung nur des Symptoms (Scheibensättigung), ohne die Ursache der Akkumulation zu untersuchen, ein Wiederauftreten des Problems garantiert. Das Fehlen einer Lifecycle Policy \(TTL/Expiration\) für Warteschlangen mit toten Buchstaben und das Fehlen einer Validierung der Nutzlastgröße vor der Veröffentlichung sind die beiden zentralen strukturellen Lücken, die korrigiert werden müssen. Darüber hinaus wurde die Warnung, die das Problem markierte, als niedrig eingestuft, was zu einer Verzögerung von etwa 38 Minuten zwischen der ausgelösten Warnung und der formellen Eröffnung des Vorfalls führte - ein inakzeptables Intervall für eine kritische Service-Degradation.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Juli 2026 um 12:51 UTCidentified

   Sehr geehrter Kunde, Wir haben eine Instabilität in der Fähigkeit zur Identitätsüberprüfung festgestellt, was zu einem Fehler in einem kleinen Teil der IDCloud-Anforderungen führte. Unser Engineering-Team ist bereits für die Diagnose und die Identifizierung der Ursache mobilisiert, um den Service so schnell wie möglich zu normalisieren. Zu diesem Zeitpunkt führt das technische Team eine detaillierte Analyse in unserer Datenschicht durch, um die Auswirkungen zu mildern. Wir betonen, dass in Kürze weitere Updates verschickt werden.

2. 13. Juli 2026 um 13:06 UTCmonitoring

   Sehr geehrter Kunde, Unser Engineering-Team hat die Maßnahmen identifiziert und implementiert, um die Instabilität der Identitätsüberprüfungsfunktion zu beheben, die einen Fehler in einem kleinen Teil der IDCloud-Anforderungen erzeugt hat. Zu diesem Zeitpunkt führt das technische Team detaillierte Analysen in unserer Datenschicht durch und überwacht weiterhin die Umgebung. Wir betonen, dass in Kürze weitere Updates verschickt werden.

3. 13. Juli 2026 um 13:47 UTCresolved

   Executive Summary und Impact Am 13. Juli 2026 haben wir eine Instabilität in unserer Fähigkeit zur Identitätsverifizierung festgestellt, die Fehler bei einem minimalen Teil der IDCloud-Anforderungen verursacht hat und mehrere Authentifizierungsströme beeinflusst. Das Problem wurde durch automatisierte Verfügbarkeitswarnungen um 9:27 Uhr BRT erkannt, mit einem leichten Anstieg der Fehler, die bereits ab ca. 8:00 Uhr BRT erkennbar waren, und einer signifikanten Verschlechterung, die um 9:07 Uhr BRT begann und den maximalen Aufprall um 9:49 Uhr BRT erreichte. Wurzelursache und Auflösung Die Wurzelursache wurde als allmähliche Änderung identifiziert, die auf eine interne Authentifizierungskomponente angewendet wurde und einen Fehler bei der Validierung der Sitzungstoken-Signatur verursachte. Sobald die Ursache bestätigt wurde, kehrte das Ingenieurteam die Änderung zurück und die Serviceverfügbarkeit wurde wieder normal. Die kritischste Phase des Aufpralls dauerte etwa 44 Minuten. Engagement und nächste Schritte Engineering evaluiert Verbesserungen des Änderungsvalidierungsprozesses für schrittweise Rollouts, die kritische Authentifizierungskomponenten betreffen, einschließlich automatischer Rollback-Mechanismen im Falle von Fehlerspitzen während dieser Art von Rollout. Ein detailliertes Postmortem wird voraussichtlich als nächster Schritt intern geteilt.

4. 20. Juli 2026 um 22:47 UTCpostmortem

   # Postmortem: Authentifizierungsfluss-Instabilität **Unfalldatum:** 13. Juli 2026 **Auswirkungsdauer:** ~44 Minuten ## Zusammenfassung Am 13. Juli 2026 haben wir eine Verschlechterung der Verfügbarkeit in den Authentifizierungsströmen der Plattform festgestellt. Der Vorfall wurde durch eine Inkompatibilität verursacht, die während eines rollenden Einsatzes einer internen Komponente eingeführt wurde, die für die Validierung von Sicherheitstoken verantwortlich ist. Die Ursache wurde von unseren Betriebsteams diagnostiziert, und das Zurücksetzen des Updates stellte die Systemstabilität innerhalb von Minuten wieder her. ## Auswirkungen Die Degradation dauerte ca. 44 Minuten und beeinflusste gleichzeitig mehrere Authentifizierungsflüsse auf der Plattform, was zu einer Fehlerrate von ca. 0,9% bei Kundendiensten führte. Während dieser Zeit erlebten einige Endbenutzer Instabilität und sahen generische Fehlermeldungen (HTTP 500), wenn sie versuchten, sich zu authentifizieren. Obwohl das Ereignis 44 Minuten dauerte, schwankte es zwischen erhöhter Latenz und Nichtverfügbarkeit. ## Wurzelursache Der Fehler wurde durch einen Softwarefehler verursacht, der bei einem Update der Sicherheitstoken-Validierungskomponente eingeführt wurde, was zu einer Inkompatibilität zwischen Instanzen mit verschiedenen Versionen führte. Diese Inkompatibilität wurde in Testumgebungen nicht erkannt, da sie die gleichzeitige, parallele Ausführung verschiedener Versionen erforderte. Darüber hinaus gab der interne Endpunkt eine HTTP-Erfolgsantwort zurück, selbst wenn die Validierung fehlschlug, was verhinderte, dass automatisierte Bereitstellungsüberwachungssysteme das Problem erkannten und den Rollout automatisch stoppten. ## Resolution Sobald die Ursache identifiziert wurde, führte das On-Call-Team ein Rollback der betroffenen Komponente durch und stellte sofort die Verfügbarkeit der Authentifizierungsströme wieder her. Der Vorfall wurde durch automatisierte SLO-Warnungen innerhalb von Minuten nach Beginn der Degradation erkannt, und die Eskalation ermöglichte eine vollständige Diagnose und Minderung des Vorfalls. ## Lektionen gelernt Wir werden die Validierung der Versionskompatibilität in rollenden Bereitstellungen verbessern, das HTTP-Antwortverhalten interner Endpunkte anpassen, um ein automatisches Rollback fehlgeschlagener Bereitstellungen auszulösen, und die Fehlerbehandlung standardisieren, um zu verhindern, dass Fehler vor dem Erreichen des Kunden maskiert werden. ## Engagement für kontinuierliche Verbesserung Vorfälle wie dieser verstärken unser Engagement für die kontinuierliche Verbesserung der Zuverlässigkeit der Plattform. Wir behandeln jeden Vorfall als Lernmöglichkeit, überprüfen unsere Prozesse, stärken Erkennungs- und Präventionsmechanismen und investieren kontinuierlich in robustere Engineering-Praktiken. Unser Ziel ist es, die Messlatte für Verfügbarkeit und Transparenz für alle unsere Kunden weiter anzuheben. Unico Team.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 10. Juli 2026 um 16:43 UTCinvestigating

   Wir erleben derzeit Instabilität bei den IDCLOUD-Fähigkeiten. Unser technisches Team untersucht bereits die Ursache. Wir werden Updates bereitstellen, sobald weitere Informationen verfügbar sind.

2. 10. Juli 2026 um 17:12 UTCidentified

   Wir haben eine Instabilität identifiziert, die zu vorübergehenden Ausfallzeiten oder Latenzzeiten in einigen unserer zentralen Verifizierungs- und Risikoanalyse-APIs führen kann. Betroffene Dienstleistungen: Identität & Validierung: Identitätsüberprüfung, 1:1 Validierung, Serpro Ähnlichkeitsrückgabe - Risk & Fraud: Risk Score, Fraud Risk Classification Dokumentation & Liveness: Document Reuse & Capture, Liveness Aktueller Status & Nächste Schritte: Unser Engineering-Team ist bereits voll engagiert und untersucht die Ursache. Wir arbeiten aktiv daran, das Verhalten zu isolieren und den normalen Betrieb so schnell wie möglich wiederherzustellen.

3. 10. Juli 2026 um 17:25 UTCmonitoring

   Aktueller Status & Nächste Schritte Mitigation Maßnahmen wurden erfolgreich angewendet, und das System ist jetzt stabil. Zu diesem Zeitpunkt überwacht unser Engineering-Team die Leistung der Plattform aktiv, um eine kontinuierliche Stabilität und einen normalen Betrieb zu gewährleisten. Vielen Dank für Ihre Geduld und Ihr Verständnis während dieses Vorfalls. Ihre Dienste sollten jetzt normal funktionieren.

4. 10. Juli 2026 um 17:57 UTCresolved

   Executive Summary und Impact Zwischen 13:21 Uhr und 14:16 Uhr (Brasília-Zeit) am 10. Juli 2026 haben wir eine Fluktuation in der Verfügbarkeit des Prozesserstellungsflusses und der damit verbundenen Reisen festgestellt, was zu einer vorübergehenden Erhöhung der Fehlerrate einiger unserer Haupt-APIs führte. - Wirkungsbereich: Die Veranstaltung betraf ausschließlich die Verfügbarkeit bestimmter Fahrten in diesem Intervall. Kunden, die in diesem Zeitraum keinen Anstieg ihrer Fehlerquote erlebten, waren nicht betroffen. Datenintegrität: Es gab keine Kompromisse bei der Integrität oder Sicherheit der verarbeiteten Informationen. - Minderung: Ein erster Workaround wurde innerhalb weniger Minuten angewendet, wodurch das Fehlervolumen gestoppt wurde. Der Service wurde um 14:16 Uhr nach der Stabilitätsbestätigung unserer Engineering- und Monitoring-Teams vollständig normalisiert. Wurzelursache Der Vorfall wurde durch Instabilität in einem Infrastrukturdienst ausgelöst, gefolgt von einer plötzlichen Verschlechterung der Initialisierung verwandter interner Komponenten. Engagement und nächste Schritte Wir sind der Widerstandsfähigkeit unserer Plattform zutiefst verpflichtet. Die während des Vorfalls eingeleiteten Korrektur- und Präventionsmaßnahmen werden bereits überwacht, um das Risiko zukünftiger Ereignisse dieser Art zu verringern. Postmortem: Ein detaillierter technischer Bericht (Postmortem) wird in Kürze veröffentlicht, der den vollständigen Zeitplan, die Architekturanalyse und einen langfristigen Aktionsplan mit definierten Fristen enthält. Wir entschuldigen uns aufrichtig für die Auswirkungen und die verursachte Instabilität. Das Vertrauen unserer Kunden hat höchste Priorität, und wir arbeiten kontinuierlich daran, die Exzellenz unserer Dienstleistungen sicherzustellen. Ehrlich gesagt, Unico Team

5. 14. Juli 2026 um 14:08 UTCpostmortem

   **Zusammenfassung** Am 10. Juli 2026, zwischen 13:21 Uhr und 14:09 Uhr \(Brasília-Zeit\), erreichte die Fehlerrate im Prozesserstellungsfluss etwa 9 Minuten lang einen Höhepunkt bei etwa 11%, wobei die Verfügbarkeit bis 14:09 Uhr weiter verschlechtert wurde. Der Vorfall wurde durch eine Instabilität in der Infrastrukturkonfigurationsmanagementkomponente verursacht, die die korrekte Initialisierung der biometrischen Service-Pods verhinderte. Der Einfluss wurde durch ein bereits bestehendes Speicherverbrauchsverhalten verstärkt (was die Häufigkeit von Pod-Neustarts erhöhte) und durch einen Traffic-Spike, der die Erstellung neuer Instanzen auslöste - die alle während des Instabilitätsfensters der Konfigurationskomponente nicht initialisiert werden konnten. **Auswirkungen** Mehrere Flüsse waren gleichzeitig betroffen - einschließlich Prozesserstellung, Authentifizierung, Biometrie, Zahlungen und interner Vorgänge - mit Fehlern, die sich über alle Dienste in Abhängigkeit von der Biometrie-Engine ausbreiten. Auf ihrem Höhepunkt erreichte die Fehlerquote 11%. Die Anzahl der verfügbaren biometrischen Service-Pods sank in beiden Produktionsclustern während des kritischsten Zeitfensters des Vorfalls auf nahezu Null. **Wurzelursache** Die Ursache lag in einer Optimierungsmöglichkeit in der Startlogik des Biometrie-Dienstes: Die Anwendung weigerte sich zu erscheinen, wenn die Infrastrukturkonfigurationsmanagementkomponente während des Bootens einen Fehler zurückgab, selbst wenn zwischengespeicherte Daten für die Verwendung als Fallback zur Verfügung standen. Diese Logik behandelte einen vorübergehenden Kommunikationsausfall genauso wie einen permanenten Konfigurationsfehler, wodurch der Fallback-Cache genau in dem Moment unbrauchbar wurde, in dem er am meisten benötigt wurde. Als die Konfigurationskomponente instabil wurde, blieb jeder Pod, der versuchte, neu zu starten - sei es aufgrund von Speicherdruck oder Autoskalierung - in einer Fehlerschleife stecken und konnte den Initialisierungsprozess nicht abschließen. **Resolution** Das Team enthielt die anfänglichen Auswirkungen, indem es den Datenverkehr von einer der betroffenen Komponenten isolierte, was die Fehlerspitze innerhalb von etwa 9 Minuten stoppte. Es folgte die Stabilisierung der Konfigurationsverwaltungskomponente, so dass Pods normal wieder hochfahren konnten. Eine Notfalllösung wurde vorbereitet und am selben Tag bereitgestellt, wodurch die restriktive Validierung, die das Starten blockierte, entfernt wurde, um sicherzustellen, dass der Fallback-Cache in ähnlichen Situationen in Zukunft transparent verwendet wird. **Lektionen gelernt** Der Vorfall ergab, dass der Resilienzmechanismus des Dienstes - der Fallback-Cache - in der Architektur existierte, aber durch die Startlogik neutralisiert wurde, die eine strenge Datenvalidierung gegenüber der Verfügbarkeit in der Umgebung priorisierte. Startpfade für kritische Dienste müssen so konzipiert sein, dass sie sich anmutig verschlechtern, wenn die unterstützenden Infrastrukturkomponenten instabil sind, wodurch die Betriebskontinuität gewährleistet ist. **Engagement für Stabilität und kontinuierliche Verbesserung** Wir werden weiterhin stark in die Robustheit unserer Infrastruktur investieren, um sicherzustellen, dass unsere Dienstleistungen auf höchstem Niveau an Effizienz, Sicherheit und Zuverlässigkeit funktionieren. Unico Team.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 22:05 UTCidentified

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

3. 3. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 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. Juni 2026 um 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. Juli 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juli 2026 um 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. Juni 2026 um 01:24 UTCinvestigating

   Prezado Cliente Nossa monitoração proativa detectou um comportamento irregular no ID Pay e no fluxo de onboarding do ByUnico. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar 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. Juni 2026 um 01:39 UTCidentified

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

3. 23. Juni 2026 um 01:53 UTCidentified

   Prezado Cliente Informamos que nossa equipe identificou a causa da instabilidade e está ativamente trabalhando na aplicação da solução. Seguimos empenhados em restabelecer 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. Juni 2026 um 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 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!

5. 23. Juni 2026 um 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 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!

6. 14. Juli 2026 um 13:58 UTCpostmortem

   **Zusammenfassung** Am 22. Juni 2026, um 9:52 Uhr \(Brasília-Zeit\), wurde der Dokumentenspeicherfluss aufgrund der Erschöpfung eines sequentiellen Bezeichnerlimits in der Datenbank nicht verfügbar. Von diesem Moment an begannen alle Dokumenteneinfügungen zu scheitern, was zu Fehlern bei mehreren abhängigen Diensten führte. Der Vorfall dauerte ca. 86 Minuten. **Auswirkungen** Mehrere kritische Dienste waren gleichzeitig betroffen – einschließlich Onboarding-Flows, Prozesserstellung, Authentifizierung und Zahlungen. In einigen Strömen sank die Verfügbarkeit auf unter 3%. Kunden hatten Benutzer von Fehlern oder Verzögerungen betroffen, wenn sie Operationen versuchten, die von der Dokumentenspeicherung abhängig waren. **Wurzelursache** Die Ursache war mit dem 32-Bit-Identifikatortyp in der Dokumententabelle verbunden, der etwa 2,1 Milliarden Werte unterstützt; Mit dem natürlichen Wachstum des Rekordvolumens im Laufe der Zeit wurde dieser Grenzwert erreicht, wodurch die Datenbank nicht mehr in der Lage war, neue Identifikatoren zu generieren, so dass alle Einfügungsvorgänge fehlschlugen. Da es keine Überwachung gab, die konfiguriert war, um die Nähe zu diesem Grenzwert zu verfolgen, erfolgte die Erschöpfung abrupt und ohne vorherige Warnung. **Resolution** Das Team identifizierte die Ursache in etwa 20 Minuten. Als sofortige Abschwächung wurde der sequentielle Bezeichner neu konfiguriert, um den negativen Bereich des gleichen Datentyps zu verwenden, wodurch etwa weitere 2,1 Milliarden Werte frei wurden, ohne dass eine strukturelle Änderung der Datenbank erforderlich war. Die Lösung wurde in niedrigeren Umgebungen validiert, bevor sie in der Produktion angewendet wurde. Der Service begann sich zu stabilisieren, kurz nachdem der Fix angewendet wurde und wurde überwacht, bis die vollständige Wiederherstellung bestätigt wurde. **Lektionen gelernt** Der Vorfall unterstreicht die Bedeutung der Implementierung einer Überwachung für die Verwendung sequenzieller Identifikatoren in großvolumigen Tabellen mit Frühwarnungen, die es ermöglichen, die Erschöpfung als geplante Wartung zu behandeln; die Einführung von 8-Byte-Identifikatortypen von Anfang an für Tabellen mit hohem Schreibvolumen, einschließlich dieser Check-in-Schemaüberprüfungsprozesse; und die Zuordnung und Dokumentation der kritischen Abhängigkeiten von Kern-Persistenzdiensten, um die Auswirkungen zu bewerten und die Kommunikation mit betroffenen Benutzern bei zukünftigen Vorfällen zu priorisieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juli 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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