Historia awarii Unico

1. 30 sierpnia 2026 02:35 UTCinvestigating

   Drogi Kliencie, Około godziny 11: 00 (BRT) w piątek, 29 sierpnia 2026 roku, zidentyfikowaliśmy niestabilność wpływającą na tworzenie procesu w IDCloud. W tym okresie niektóre wnioski mogą być nieskuteczne lub wystąpić wolniej niż zwykle. Zdajemy sobie sprawę z niedogodności, jakie może to spowodować i doceniamy pańskie zrozumienie. Wkrótce zostanie dostarczona nowa aktualizacja. Unico Team

2. 30 sierpnia 2026 02:49 UTCidentified

   Nasz zespół inżynieryjny odwzorował pochodzenie niestabilności wpływającej na tworzenie procesu w IDCloud. Zespół techniczny rozpoczął już stosowanie środków naprawczych, w tym skalowanie zasobów w danej warstwie i ciągłe monitorowanie kluczowych wskaźników. Przywracanie usługi odbywa się z najwyższym priorytetem i pełną mobilizacją inżynieryjną. Powtarzamy, że kolejne aktualizacje zostaną wkrótce przesłane. Unico Team

3. 30 sierpnia 2026 02:57 UTCmonitoring

   Drogi Kliencie, Nasz zespół inżynieryjny przeprowadził działania naprawcze niezbędne do rozwiązania problemu niestabilności w tworzeniu procesów w IDCloud. Środowisko wróciło do stabilności, a wskaźniki dostępności i czasu reakcji powróciły do normalnego poziomu operacyjnego od godziny 11: 48 PM (BRT). Usługa jest dostępna do normalnego użytku. W tym czasie nasz zespół techniczny pozostaje pod obserwacją, uważnie obserwując środowisko, aby zapewnić konsekwentne działanie i działać natychmiast w przypadku jakichkolwiek wahań. Doceniamy pańskie zrozumienie i ponownie stwierdzamy, że kolejne aktualizacje zostaną wkrótce przesłane. Unico Team

4. 30 sierpnia 2026 03:15 UTCresolved

   Drogi Kliencie, Streszczenie i wpływ Między 23: 00 a 23: 48 (BRT) w dniu 29 sierpnia 2026 r., w IDCloud doszło do awarii procesu tworzenia. Podczas tego okna niektórzy klienci korzystający z tych przepływów doświadczyli niepowodzeń i zwiększonego czasu reakcji, wraz z rozprzestrzenianiem się na podróże zależne, w tym uwierzytelnianie, rejestrowanie dokumentów i dostarczanie powiadomień. Nie było kompromisu dla integralności lub bezpieczeństwa przetwarzanych informacji, a dane nie zostały utracone. Wskaźniki wróciły do normalnego poziomu operacyjnego o godzinie 11: 48 PM (BRT), z normalizacją potwierdzoną zarówno w naszym monitorowaniu, jak i po stronie klienta, obejmującą tworzenie i ukończenie procesu. Przyczyna i rozdzielczość Pochodzenie zostało zidentyfikowane w warstwie danych: wewnętrzna procedura konserwacji została zablokowana, a działania aplikacyjne zaczęły być w kolejce za nią aż do wyczerpania dostępnego limitu podłączenia, zmniejszając zdolność przetwarzania. Nasz zespół inżynieryjny chirurgicznie zakończył tylko zaciętą rutynę, natychmiast zwalniając kolejkę. Połączenia i zdolności przetwarzania zostały w pełni przywrócone, bez zmian danych. Zaangażowanie i kolejne kroki Nasz zespół inżynieryjny skupi się na trzech frontach: ograniczaniu czasu oczekiwania na wewnętrzne procedury konserwacji, zapobieganiu równoczesnym procedurom działania przeciwko tej samej strukturze oraz wzmocnieniu odporności usług na wahania warstw danych. Niebawem zostanie udostępniony szczegółowy pośmiertny plan działań wraz z pełnym harmonogramem i planem działań z terminami. Serdecznie przepraszamy za wpływ na Państwa działania i pozostajemy dostępni za pośrednictwem naszych kanałów wsparcia. Unico Team

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 sierpnia 2026 20:26 UTCidentified

   Drogi kliencie, Wykryliśmy wpływ na niektóre żądania IDCloud, wpływając na zdolność Alert zachowania (IDTrust) i przepływ 1: N. Niestabilność ta może również wpływać na klientów w Meksyku, którzy korzystają z tej zdolności. Nasz zespół inżynieryjny jest zmobilizowany, by jak najszybciej rozwiązać ten problem. Wkrótce dostarczymy nowe aktualizacje.

2. 10 sierpnia 2026 20:29 UTCmonitoring

   Nasz zespół inżynieryjny zidentyfikował i wdrożył działania niezbędne do rozwiązania problemu niestabilności w zdolnościach przepływu IDCloud. W tym czasie zespół techniczny prowadzi szczegółową analizę naszej warstwy danych i nadal monitoruje środowisko. Powtarzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

3. 10 sierpnia 2026 21:01 UTCresolved

   Streszczenie i wpływ Około godziny 17: 08 automatyczny alarm wykrył spadek dostępności w serwisie rozpoznawania twarzy (przepływ 1: N), wywołując ten incydent. Problem eskalował szybko i zaczął wpływać na zachowanie ostrzegające usługi, a następnie, przepływ tworzenia procesu, z powodu kaskadowych przerw między tymi usługami. Wpływ ten wpłynął na podzbiór klientów wykorzystujący te możliwości. Sytuacja została zgłoszona jako ustabilizowana o 17: 22, a wskaźniki wracają do normalnego poziomu. Przyczyna i rozdzielczość Przyczyną był wzrost ruchu spowodowany wewnętrznym obciążeniem pracą, który wysłał dużą ilość wniosków o rozpoznawanie twarzy bezpośrednio do rurociągu biometrycznego, omijając warstwę krawędzi używaną przez normalny ruch klienta. Ta dodatkowa objętość nasyciła pojemność bazy danych wspierającej usługę rozpoznawania twarzy. Saturacja spowodowała w tej usłudze przerwy w czasie, które kaskadowały się na usługi biometrycznej orkiestracji silników, a następnie na usługi ostrzegające o zachowaniu, i wreszcie na tworzenie procesu przepływu przy użyciu tych możliwości. Aby rozwiązać problem, zespół zatrzymał obciążenie pracą odpowiedzialne za skok i zwiększył pojemność dotkniętej bazy danych. Działania te złagodziły problem, a ilość błędów powróciła do poziomu bliskiego zeru. Zaangażowanie i kolejne kroki W celu wprowadzenia ograniczenia stawki dla rodzaju wewnętrznego obciążenia pracą, które spowodowało wzrost, otwarto kolejny element, jako środek zapobiegawczy przeciwko nawrotom. Wzrost mocy produkcyjnych w odniesieniu do danej bazy danych został już przeprowadzony podczas samego incydentu.

4. 25 sierpnia 2026 13:05 UTCpostmortem

   / Podsumowanie W dniu 10 sierpnia 2026 r., między 17: 08 a 17: 27 PM\ (czas Brasília\), wskaźnik dostępności dla 1: N przepływu rozpoznawania twarzy spadł poniżej 95%, z całkowitym wpływem około 19 minut. Incydent został spowodowany nasyceniem bazy wektorowej używanej przez silnik biometryczny, wynikającym z nieoczekiwanego zachowania w mechanizmie zużycia kolejki, który wygenerował głośność wywołania 2,36 razy wyższą niż skonfigurowany. Nadmiar obciążenia osiągnął maksymalny limit skalowania bazy danych, powodując kaskadowe timeout w wielu zależnych usług i wpływając na 55 użytkowników klientów z błędami w okresie. * * Uderzenie * * Użytkownicy rozpoznawania twarzy, uwierzytelniania i tworzenia procesów płyną z wielu klientów doświadczyli błędów i przerw czasowych w tym okresie. Saturacja bazy danych była kaskadowana przez usługi biometrycznej orkiestracji, silnika i tworzenia procesów. Migrację przeprowadzono poprzez wyłączenie usługi wewnętrznej i zwiększenie maksymalnego limitu skalowania bazy danych, stabilizując usługę o 17: 27. * * Root Cause * * Przyczyną było połączenie czynników związanych z zachowaniem usług i przepustowością infrastruktury. Usługa została skonfigurowana z limitem 2 żądań na sekundę, ale mechanizm zużycia kolejki zachował się niespodziewanie: wiadomości, których przetwarzanie przekroczyło termin potwierdzenia zostały ponownie dostarczone przez kolejkę bez anulowania oryginalnej realizacji - zamieniając 938 elementów pracy w 2,217 efektywnych połączeń\ (~ 8.4 RPS\). Ten wzmocniony ruch dotarł do bazy danych bez przechodzenia przez warstwę ochronną krawędzi, co normalnie ograniczyłoby wielkość zapotrzebowania, ponieważ ścieżka sieciowa użyta w tym przepływie nie przeszła przez te urządzenia sterujące. Baza danych, działająca już blisko maksymalnego limitu skalowania, nie była w stanie wchłonąć dodatkowego obciążenia - jej procesor osiągnął 88% podczas skalowania do konfigurowanego sufitu 100 węzłów - i opóźnienie zapytania skoczyło z ~ 3 sekund do ~ 18,75 sekund w p90, rozsiewania timeout w całym łańcuchu usług zależnych. * * Resolution * * Zespół zidentyfikował ten proces jako źródło ładunku w ciągu kilku minut od wpisu. Proces został wyłączony, a maksymalny limit skalowania w bazie danych został zwiększony z 100 do 150 węzłów. Dzięki tym dwóm działaniom służba ustabilizowała się o 17: 27. * * Lessons Learned * * Incydent pokazał, że ograniczenie stawki stosowane tylko po stronie publikacji wiadomości jest niewystarczające, gdy konsument może zwiększyć objętość poprzez przekierowanie. Również po stronie konsumpcji muszą istnieć kontrole stóp procentowych i kontroli wzajemnych. Ponadto usługi wewnętrzne, które mają dostęp do kluczowych elementów poprzez ścieżki, które omijają zabezpieczenia krawędzi stanowią ryzyko strukturalne - każdy klient wewnętrzny może generować niekontrolowane obciążenie wspólnej infrastruktury.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 lipca 2026 12:42 UTCinvestigating

   Klienci Prezados, Identificamos uma instabilidade técnica pontual que afeta a atulizaçã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 possibível. Pedimos desculpas pelo incommente e manteremos todos informados sobre o progresso. Atenciosamente,

2. 31 lipca 2026 13:08 UTCidentified

   Klienci Prezados, Gostaríamos de atulizar 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 atraulização assim que a correção for contriída e entrarmos na fase de monitoramento. Atenciosamente,

3. 31 lipca 2026 13:20 UTCmonitoring

   Klienci Prezados, 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 lipca 2026 14:06 UTCresolved

   Klienci Prezados, 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 listagiem e o histórico de documentos foram totalmente restabelecidos, e a plataforma opera em completa estabilidade. Agradecemos pela consumensão e paciência de todos durante o processo. Atenciosamente,

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 lipca 2026 14:04 UTCresolved

   Streszczenie i wpływ Informujemy, że incydent tymczasowo wpływający na usługę powiadamiania ID Cloud Webhook został rozwiązany. Okres oddziaływania: od 08: 32 do 10: 05. Platforma Impact: Niestabilność była ściśle ograniczona do dostawy powiadomień Webhook, co spowodowało opóźnienie w dystrybucji wiadomości. Nie było degradacji głównej platformy, żadnych awarii silnika liwitacyjnego, ani utraty danych. Wpływ na klienta: Problem dotyczył niewielkiej części klientów. Klienci, którzy wdrożyli przepływ sondaży GET jako awaryjny (awaryjny) nie doświadczyli przestojów ani skutków operacyjnych. Przyczyna i rozdzielczość Przyczyna korzenia: Niestabilność została wywołana przez aktualizację funkcji w środowisku. Tymczasowe niedopasowanie uprawnień dostępu pomiędzy kolejką zadań a trasą docelową spowodowało odrzucenie wniosków, co doprowadziło do tymczasowego zaległości w powiadomieniach. Resolutive Action: Zespół techniczny zakończył przekierowanie ruchu do nowego środowiska, przywracając właściwą komunikację między komponentami i uwalniając zaległości Webhacks. Przetwarzanie wróciło do normy, a kolejka wysyłkowa została w pełni oczyszczona. Zaangażowanie i kolejne kroki Stabilność naszych usług jest naszym najwyższym priorytetem. Aby zapewnić całkowitą przejrzystość i zapobiec nawrotom, nasz zespół inżynieryjny skupi się na następujących frontach: Szczegółowy pośmiertny: przygotowany zostanie kompleksowy raport zawierający analizę przyczyn niegłębokich oraz plan działań zapobiegawczych. Poprawa obserwacji: Dostosujemy wskaźniki monitorowania, aby zapewnić większą widoczność błędów w komunikacji międzyusługowej podczas scenariuszy przejściowych. Serdecznie przepraszamy za niedogodności i pozostajemy dostępni za dalsze wyjaśnienia. Z poważaniem, Unico Team

2. 7 sierpnia 2026 13:08 UTCpostmortem

   / Podsumowanie W dniu 29 lipca 2026 r., między 8: 32 a 10: 05 rano\ (czas Brasília\), usługa dostarczania haka została zniszczona na około 1 godzinę i 33 minuty. Incydent został spowodowany planowaną migracją infrastrukturalną, która stworzyła stan przejściowej niezgodności: po przełączeniu tras wewnętrznych na nowy klaster, serwis hakowy zaczął generować żetony uwierzytelniające z nowego klastra, ale dostawy były nadal kierowane do starego klastra - który odrzucił żetony z błędem autoryzacji. Utracone wydarzenia były ponownie przetwarzane na żądanie. * * Uderzenie * * Jednocześnie wpłynęło to na wiele produktów - w tym na uwierzytelnianie, płatności i przepływy pokładowe. Użytkownicy klientów, którzy oparli się wyłącznie na powiadomieniach dotyczących haków internetowych, aby kontynuować swoje przepływy biznesowe, doświadczyli zakłóceń operacyjnych w tym okresie. Klienci, którzy wdrożyli aktywne sondaże jako mechanizm awaryjny, odczuli ograniczony wpływ. * * Root Cause * * Podstawową przyczynę stwierdzono w planowaniu migracji: procedura nie odwzorowała skutej zależności przepływu haka webowego - gdzie wewnętrzna trasa tworzy asynchroniczne zadanie, które z kolei wywołuje publiczną trasę dostawy. Migrując trasami wewnętrznymi i drogami publicznymi w odrębnych etapach, stworzono okno niekompatybilności, w którym żetony generowane przez nowy klaster zostały odrzucone przez politykę autoryzacji starego klastra, która w szczególności zatwierdziła poprzedni identyfikator rachunku usług. Scenariusz ten nie został zidentyfikowany podczas oceny ryzyka dokonanej przez zmianę, a żaden z istniejących wskaźników jakości usług nie obejmował asynchronicznej warstwy dostaw, w której doszło do niepowodzenia. * * Resolution * * Zespół zidentyfikował niezgodność symbolu jako źródło awarii i zakończył migrację publicznych tras do nowego klastra, eliminując rozbieżności. Od tego momentu dostawy w kolejce rozpoczęły się normalnie. Uderzenie ustało o 10: 05, a ruch na starym klastrze osiągnął zero o 10: 32. * * Lessons Learned * * Incydent pokazał, że migracje związane z łańcuchem asynchronicznych przepływów dostaw wymagają, aby wszystkie trasy uczestniczące w łańcuchu - wewnętrzne i publiczne - były migrowane w skoordynowany sposób, bez niekompatybilności między klastrami. Stosowane podejście stopniowe, choć odpowiednie dla większości migracji, stworzyło dłuższy okres niepowodzenia, którego można było uniknąć poprzez przejście atomowe lub znacznie krótszy okres przejściowy. Ponadto brak widoczności na asynchronicznej warstwie nośnej był powodem, dla którego incydent nie został wykryty wewnętrznie - istniejące wskaźniki mierzone były jedynie akceptacją zdarzeń, a nie faktyczną dostawą. Stworzenie specjalnych ostrzeżeń na wypadek awarii i zaległości w tej warstwie jest najpilniejszą poprawą monitorowania zidentyfikowaną.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 lipca 2026 21:47 UTCinvestigating

   Drogi Kliencie, Obecnie badamy niestabilność w naszych hakach, która wpływa na opóźnienie w dostarczaniu danych. Nasz zespół inżynieryjny aktywnie pracuje nad jak najszybszym rozwiązaniem problemu. Wkrótce dostarczymy dalsze aktualizacje.

2. 24 lipca 2026 21:53 UTCmonitoring

   Drogi Kliencie, Nasz zespół inżynieryjny zidentyfikował i wdrożył niezbędne działania, aby rozwiązać niestabilność Webhook wpływającą na opóźnienie dostarczania danych. W tym czasie zespół techniczny prowadzi szczegółową analizę naszej warstwy danych i nadal monitoruje środowisko. Powtarzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

3. 24 lipca 2026 22:18 UTCresolved

   Streszczenie i wpływ Począwszy od 6: 05 PM (czas Brasília), w serwisie Webhook wystąpiła niestabilność, prowadząca do niepowodzenia w przetwarzaniu zdarzeń i powiadamianiu o operacjach w tym okresie. Przyczyna i rozdzielczość Incydent został spowodowany problemem z kontem usług współdzielonych wykorzystywanym w wielu usługach, co doprowadziło do awarii uwierzytelniania. Po zidentyfikowaniu przyczyny, zespół inżynieryjny przywrócił wymagane kwalifikacje i konfigurację. Normalna operacja została w pełni przywrócona o godz. 18.29 (BRT). Zaangażowanie i kolejne kroki W ramach ciągłego doskonalenia i ograniczania ryzyka zespół inżynieryjny dokona przeglądu zależności zasobów i zarządzania dostępem w ramach różnych usług. Zapobiega to podobnym problemom konfiguracji w przyszłych dostosowaniach infrastruktury.

4. 3 sierpnia 2026 20:00 UTCpostmortem

   / Podsumowanie 24 lipca 2026 r., między 18: 05 PM a 18: 29 PM\ (czas Brasília\), tworzenie i dostarczanie haka przez około 24 minuty było niedostępne. Incydent został spowodowany utratą dostępu do rachunku usług infrastrukturalnych podczas procesu likwidacji zasobów związanego z migracją klastrów przeprowadzoną kilka dni wcześniej. Konto, na które wpłynął problem, było współdzielone przez wiele usług bez udokumentowania tej zależności, co spowodowało utratę zdolności uwierzytelniania przez serwis webhook i zaprzestanie tworzenia i dostarczania wydarzeń. * * Uderzenie * * Tworzenie i dostawa zdarzeń webhook została przerwana w tym okresie, dotykając 18 użytkowników z więcej niż 1,550 błędów zarejestrowanych. Wpływ ten został skasowany na inne usługi, które zależały od tego samego przepływu uwierzytelniania, powodując jednoczesną degradację różnych możliwości platformy. * * Root Cause * * Przyczyna została zidentyfikowana w konfiguracji zależności usług. Ta zależność międzyusługowa nie była udokumentowana ani widoczna w żadnym mapowaniu zależności. Gdy proces likwidacji został usunięty z rachunku w ramach pierwotnego oczyszczania zasobów usługi, nie było automatycznej walidacji w celu sprawdzenia, czy rachunek jest nadal wykorzystywany przez inne aktywne usługi. Brak tego zabezpieczenia utrzymywał zależność w ukryciu, dopóki jej usunięcie nie spowodowało szeroko zakrojonych błędów uwierzytelniających. * * Resolution * * Zespół szybko zidentyfikował niestabilne konto usług jako źródło awarii uwierzytelniania. Konto zostało ręcznie dostosowane i przystosowane do klastra, przywracając usługę o 6: 29 PM. Całkowity czas oddziaływania wynosił około 24 minut. * * Lessons Learned * * Incydent ujawnił zagrożenia wynikające z dotychczasowych konfiguracji, które tworzą ukryte zależności między usługami: jedna zmiana zasobów podczas planowanej konserwacji była wystarczająca, aby zakłócić jednocześnie wiele usług. Proces likwidacji zasobów infrastruktury musi obejmować automatyczne zatwierdzanie zależności przed jakąkolwiek zmianą.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 lipca 2026 16:39 UTCidentified

   Drogi kliencie, Badamy niestabilność funkcji IDCloud, która wpływa na przepływ uwierzytelniania podczas podróży procesowej, szczególnie wpływając na podróż internetową (dawniej ByUnico). Nasz zespół inżynieryjny jest zmobilizowany, by jak najszybciej rozwiązać ten problem. Wkrótce dostarczymy dalsze aktualizacje.

2. 21 lipca 2026 16:49 UTCmonitoring

   Drogi Kliencie, Nasz zespół inżynieryjny zidentyfikował i wdrożył działania niezbędne do rozwiązania problemu niestabilności w zdolnościach przepływu IDCloud. W tym czasie zespół techniczny prowadzi szczegółową analizę naszej warstwy danych i nadal monitoruje środowisko. Powtarzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

3. 21 lipca 2026 18:02 UTCresolved

   Streszczenie i wpływ Począwszy od około 12: 44 PM (czasu Brasília) w dniu 21 lipca 2026 r., część użytkowników w zmniejszonej podróży pokładowej doświadczyła wolniejszego ładowania początkowych ekranów w przepływie. Wpływ zaobserwowano we wszystkich środowiskach, w których ta podróż jest wykorzystywana, wpływając na postrzeganą prędkość i w mniejszym stopniu na zdolność użytkowników do zakończenia procesu w tym okresie. Przyczyna i rozdzielczość Dochodzenie jest w toku w celu potwierdzenia ostatecznej przyczyny incydentu. Nie stwierdzono wpływu na serwery, sieć czy infrastrukturę - problem został potwierdzony jako izolowany od doświadczeń na ekranie urządzenia użytkownika. Jako środek zapobiegawczy, odpowiedzialny zespół zastosował korektę zapobiegawczą o 1: 39 PM (BRT), a czas załadunku powrócił do normy w ciągu kilku minut. Analiza potwierdzająca i potwierdzająca przyczynę jest nadal przeprowadzana przez zespół techniczny. Zaangażowanie i kolejne kroki W ramach ciągłego doskonalenia procesów reagowania na incydenty zespół zobowiązuje się do zwiększenia automatycznego przepływu eskalacji dla odpowiedzialnych zespołów, czyniąc aktywację jeszcze bardziej bezpośrednią i skuteczną od momentu otwarcia incydentu. Dodatkowo, monitorowanie prędkości obciążenia zostanie wzmocnione podczas wprowadzania nowych zmian w tej podróży, w celu zidentyfikowania i skorygowania potencjalnych regresji jeszcze szybciej, minimalizując wpływ na użytkowników w podobnych sytuacjach idących naprzód.

4. 3 sierpnia 2026 14:01 UTCpostmortem

   / Podsumowanie 21 lipca 2026 r., między 12: 44 PM a 1: 43 PM\ (czas Brasília\), wskaźniki wydajności obciążenia strony dla zmniejszonej trasy poważnie zdegradowanej, ze średnim czasem obciążenia skoki z ~ 4,8 do ~ 8,9 i p95 do 31.5 sekund. Incydent został spowodowany ograniczeniem stawek stosowanych przez infrastrukturę chmur na połączeniach pochodzących od usługodawcy, co uniemożliwiło załadowanie aktywów na frontach. * * Uderzenie * * Użytkownicy z 32 klientów doświadczyli bardzo powolnych obciążeń strony lub kompletnych awarii ładowania, z około 94 błędów podróży rejestrowane. Błędy "Initialization Timeout" - wywołane, gdy aplikacja nie włączy się w ciągu 30 sekund - osiągnęły w tym okresie około 23 tys. zdarzeń. * * Root Cause * * Podstawową przyczynę zidentyfikowano w warstwie sieciowej infrastruktury: dostawca CDN konsoliduje ruch poprzez ograniczony zestaw zewnętrznych adresów IP. Zaostrzenie nowych połączeń TCP i uścisków dłoni TLS pochodzących z tych IP wywołało automatyczne mechanizmy obrony warstw sieciowych w chmurze, które rozpoczęły się od ograniczających rate- połączeń jeszcze przed przetwarzaniem HTTP. Ponieważ te awarie wystąpiły na warstwie sieciowej - przed przetwarzaniem HTTP - nie pojawiły się w standardowych dziennikach zapytań, co sprawia, że problem niewidoczny do konwencjonalnego monitorowania i znacznie komplikuje diagnozę. * * Resolution * * Skutki te ustały wraz z naturalną poprawą poziomu ograniczenia stawek stosowanych przez infrastrukturę chmur. Dezaktywacja składnika, początkowo oznaczona jako możliwa przyczyna, zbiegła się czasowo z odzyskaniem, ale później została potwierdzona jako niezwiązana z incydentem. Poprawki konfiguracyjne - umożliwiające HTTP Keep- Alive z wydłużonym czasem i dodawanie reguły zezwolenia dla IP CDN w warstwie ochrony krawędzi - zostały zidentyfikowane jako następujące elementy przez zespoły wsparcia zainteresowanych dostawców. * * Lessons Learned * * W zdarzeniu podkreślono, że awarie na poziomie sieci pomiędzy CDN a infrastrukturą w chmurze są niewidoczne dla standardowego monitorowania aplikacji, co stwarza znaczący ślepy punkt. Jako kolejne elementy, zespół zidentyfikował potrzebę wdrożenia poprawek konfiguracyjnych zalecanych przez dostawców i zwiększenia obserwowalności na poziomie dostawy aktywów w celu aktywnego wykrywania tego rodzaju degradacji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 lipca 2026 14:39 UTCidentified

   Drogi kliencie, Badamy niestabilność naszych możliwości IDCloud, wpływając na proces tworzenia i szczegóły procesu płynie. Nasz zespół inżynieryjny jest zmobilizowany, by jak najszybciej rozwiązać ten problem. Wkrótce dostarczymy dalsze aktualizacje.

2. 21 lipca 2026 14:46 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

3. 21 lipca 2026 14:50 UTCmonitoring

   Drogi Kliencie, Nasz zespół inżynieryjny zidentyfikował i wdrożył działania niezbędne do rozwiązania problemu niestabilności w zdolnościach przepływu IDCloud. W tym czasie zespół techniczny prowadzi szczegółową analizę naszej warstwy danych i nadal monitoruje środowisko. Powtarzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

4. 21 lipca 2026 16:00 UTCresolved

   Streszczenie i wpływ 21 lipca 2026 roku o godzinie 11: 17 rano wykryto spadek dostępności w przepływach kreacji iDCloud i zapytania procesowego. Podczas okna uderzenia część klientów doświadczyła zwiększonego opóźnienia i awarii (timeout) w tych operacjach, które rozprzestrzeniły się przez łańcuch usług zależnych. Efektywny wpływ skoncentrowano w około 23 minutach. Na szczycie wskaźniki błędu i opóźnienia były powyżej normalnych poziomów operacyjnych. Przyczyna i rozdzielczość Dochodzenie wskazało na degradację odczytu bazy danych (repliki) wspierającej te możliwości jako źródła. Ta baza danych zaczęła wykazywać zwiększony czas realizacji obciążenia i zapytania, z wewnętrznym twierdzeniem, że blokował przetwarzanie i kopie zapasowe żądania odczytu. W rezultacie powyższe usługi zaczęły gromadzić przerwy czasowe i uruchamiać mechanizmy ochronne (wyłączniki), wytwarzając efekt kaskadowy, którego doświadczają klienci. Zaangażowanie i kolejne kroki Unico zajmuje się tym incydentem ze szczegółowym pośmiertnym, już przygotowywanym i zorganizuje spotkanie po incydencie (PiR) w celu skonsolidowania działań zapobiegawczych. Wśród działań następczych, które zostały już poruszone w trakcie reakcji, są przygotowanie procedur diagnostycznych i zapytań w celu przyspieszenia identyfikacji sporów w tej warstwie bazy danych, a także poprawa obserwowalności nad odnośnymi bazami danych. Szczegółowe działania zapobiegawcze będą dzielone w sekcji zwłok. Potwierdzamy nasze zaangażowanie na rzecz stabilności i wiarygodności platformy i przepraszamy za niedogodności spowodowane w okresie niestabilności. Drużyna Unico.

5. 28 lipca 2026 12:10 UTCpostmortem

   / Podsumowanie 21 lipca 2026 r., pomiędzy 11: 41 a 11: 43 AM\ (czas Brasília\), przepływ tworzenia procesu stał się niedostępny, przy czym główny poziom błędu w obsłudze osiągnął 42% i p99 opóźnienie na 15.75 sekund. Incydent został spowodowany nasyceniem bazy biometrycznej odczytu repliki: pula pamięci bazy danych nie była już w stanie obsługiwać najczęściej dostępnego zbioru danych, powodując zwykle szybkie zapytania, aby wrócić do odczytu dysku, tworząc samowzmacniającą spiralę zgromadzonych sesji i zwiększając opóźnienie. * * Uderzenie * * Użytkownicy procesu tworzenia, uwierzytelniania i płatności przepływają przez wielu klientów otrzymywały błędy i timeout w okresie. Podstawowa baza danych pozostała nienaruszona przez cały incydent - awaria została odizolowana do odczytu repliki. * * Root Cause * * Główną przyczyną było nasycenie: zapytania wykorzystywane w strumieniu uwierzytelniania były wykonywane rozległe skany na tabelach krytycznych z powodu brakujących indeksów. W normalnych warunkach zachowanie to było tolerowane przez infrastrukturę bazy danych. Kiedy pojemność pamięci osiągnęła swój limit i nie mogła już przechowywać najczęściej dostępnych danych w pamięci podręcznej, każdy odczyt zaczął pobierać dane z dysku, co spowodowało, że koszt każdego zapytania wykładniczo wzrósł. Ten gwałtowny efekt załamania - gdzie stopniowa degradacja ustępuje powszechnemu niepowodzeniu - stał się samowzmacniający, gdy sesje zgromadzone czekając na odpowiedzi i wewnętrzny argument bazy danych zwiększały się. Ponadto wszystkie odczyty ruchu dla przepływu krytycznego koncentrowały się na jednej replice, bez dystrybucji lub alternatywnej trasy, eliminując odporność na tego typu degradację. * * Resolution * * Baza danych odzyskała się naturalnie po wyczerpaniu skumulowanych sesji, nie wymagając ręcznej interwencji. Zespół przeszedł do bazy danych i monitorował stabilizację usług. Incydent został zamknięty po potwierdzeniu, że normalna operacja została przywrócona. * * Lessons Learned * * Incydent ujawnił luki strukturalne w warstwie bazy danych: brakujące indeksy krytycznych zapytań i koncentracja wszystkich odczytów ruchu na jednej replice bez alternatywnej trasy. Jako kontynuacje, zespół priorytetowo tworzenie brakujących indeksów, dystrybucja ruchu odczytu w repliki, i budowanie podręczników diagnostycznych w celu przyspieszenia reakcji w przyszłych incydentach o podobnym charakterze.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 20 lipca 2026 12:33 UTCidentified

   Drogi Kliencie, Zidentyfikowaliśmy niestabilność w niektórych z naszych możliwości IDCloud, wpływając na GetSelfie, tworzenie procesów i szczegóły procesu płynie dla Podróż Web (dawniej ByUnico). Przepływy API Journey (ByClient) nie zostały naruszone. Nasz zespół inżynieryjny jest zmobilizowany, by jak najszybciej rozwiązać ten problem. Wkrótce będziemy kontynuować dalsze aktualizacje.

2. 20 lipca 2026 12:35 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

3. 20 lipca 2026 12:39 UTCmonitoring

   Drogi Kliencie, Nasz zespół inżynieryjny zidentyfikował i wdrożył działania niezbędne do rozwiązania problemu niestabilności w zdolnościach przepływu IDCloud. W tym czasie zespół techniczny prowadzi szczegółową analizę naszej warstwy danych i nadal monitoruje środowisko. Powtarzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

4. 20 lipca 2026 13:22 UTCresolved

   Streszczenie i wpływ Zidentyfikowaliśmy niestabilność wpływającą na przepływ procesu przechwytywania i wizualizacji, jak również uwierzytelnianie, dla Podróży WWW, z oddziaływaniem między 09: 07 a 09: 21 (BRT). Wpływ ten dotarł do części klientów korzystających z tego przepływu; Podróż API nie została naruszona. Przyczyna i rozdzielczość Przyczyna jest związana ze zmianą konfiguracji zastosowaną w produkcji, co spowodowało zwiększenie obciążenia wewnętrznego komponentu bazy danych. Zwiększone obciążenie zwiększyło opóźnienie i błędy w warstwie integracyjnej, co z kolei wywołało mechanizm ochronny i tymczasowo przerwało przepływ WWW. Zespół inżynieryjny cofnął zmianę konfiguracji, aby złagodzić problem, a sytuacja znormalizowana wkrótce potem. Zaangażowanie i kolejne kroki Zespół inżynieryjny nadal monitoruje środowisko po wycofaniu wprowadzonych zmian. Szczegółowy pośmiertny będzie dzielony przez nasz zespół w najbliższych dniach. Przepraszamy za niedogodności. Drużyna Unico!

5. 4 sierpnia 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.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lipca 2026 14:02 UTCinvestigating

   Drogi Kliencie, Badamy niestabilność naszego systemu uwierzytelniania portali Unico People, a także oceniamy problemy w naszym serwisie komunikacyjnym dotykającym klientów IDCloud. Nasz zespół inżynieryjny jest zmobilizowany, by jak najszybciej rozwiązać ten problem. Wkrótce dostarczymy aktualizacje.

2. 16 lipca 2026 14:08 UTCmonitoring

   Drogi Kliencie, Nasz zespół zidentyfikował problem i podjął działania, aby rozwiązać ten incydent. Doświadczyliśmy niestabilności w naszym systemie uwierzytelniania portali Unico People, a także problemów w naszym serwisie wiadomości wpływających na klientów w przepływie IDCloud, dla wiadomości SMS i e-mail. Nasz zespół inżynieryjny pozostaje zmobilizowany, monitorując środowisko, aby zapewnić jego prawidłowe funkcjonowanie.

3. 16 lipca 2026 15:28 UTCresolved

   Streszczenie i wpływ O 10: 51 rano w dniu 07 / 16 / 2026, problem został zidentyfikowany w serwisie uwierzytelniania na portalu przyjmowania osób Unico oraz w wiadomości, co miało wpływ na dostarczanie wiadomości SMS i e-mail do klientów Unico People i IDCloud, a także uwierzytelnianie klienta B2C na portalu przyjmowania osób Unico. Wpływ był ograniczony do tych dwóch przepływów i nie wpłynął na kluczową podróż produktu. Incydent trwał około 30 minut, aż do pełnego rozwiązania. Przyczyna i rozdzielczość Przyczyną jest ciśnienie w pamięci jednego węzła klastra wiadomości, który osiągnął krytyczny próg dysku, degradując przetwarzanie kolejek odpowiedzialnych za dostarczanie wiadomości i uwierzytelnianie. Zespół inżynieryjny zwiększył pojemność magazynową klastra o około 10: 59, co pozwoliło na normalizację kolejek i wskaźników monitorowania w ciągu kilku minut. Środowisko było monitorowane do czasu potwierdzenia pełnego powrotu do zdrowia, a incydent został zamknięty o 11: 20. Zaangażowanie i kolejne kroki Zespół inżynieryjny dokona przeglądu kryteriów eskalacji alarmów i ustalania priorytetów dla tego rodzaju degradacji, ponieważ wpisy prawidłowo wskazały problem, ale można poprawić automatyczny przepływ eskalacji do odpowiedzialnego zespołu. W najbliższych dniach przygotowywana jest szczegółowa sekcja zwłok.

4. 3 sierpnia 2026 12:14 UTCpostmortem

   / Podsumowanie 16 lipca 2026 r., między 10: 12 a 11: 10 rano\ (czas Brasília\), usługa komunikacyjna i uwierzytelniania została zniszczona na około 58 minut. Przyczyną było nasycenie dysku na jednym z węzłów w klastrze kolejki wiadomości, który po osiągnięciu skonfigurowanego limitu automatycznie zablokował wszystkich wydawców, powodując zaległości do 33 tysięcy wiadomości w kolejce. Wpływ ten wpłynął na dostarczenie linków uwierzytelniających poprzez SMS i e-mail, jak również na przepływ uwierzytelniania użytkownika końcowego na portalu przyjmowania osób Unico. * * Uderzenie * * Użytkownicy oczekujący na połączenia uwierzytelniające przez SMS lub e-mail nie otrzymali ich w tym okresie. Użytkownicy końcowi produktu do zarządzania ludźmi próbującego uwierzytelnić na portalu dostępu nie byli również w stanie uzyskać dostępu do usługi. Uderzenie zostało zawarte po powiększeniu dysku klastra. * * Root Cause * * Przyczyna powstania została zidentyfikowana w strumieniu przetwarzania wiadomości: nadmiernie duże ładunki - generowane przez komponent audytu, który zawierał niepotrzebne dane - przekroczyły limit wielkości zaakceptowany przez klaster kolejki wiadomości. Ponieważ zostały one definitywnie odrzucone przy każdej próbie, wiadomości te zostały przekierowane do kolejki liter po wyczerpaniu wszystkich powtórzeń. Te kolejki nie miały polityki ważności ani automatycznego czyszczenia, powodując gromadzenie wiadomości w nieskończoność i stopniowo zużywają przestrzeń dyskową klastra. * * Resolution * * Dysk klastra został rozszerzony do 500 GB na węzeł, co natychmiast znormalizowało kolejki i wskaźniki klastra. Służba wróciła do normy o 11: 10. Strukturalna przyczyna - nieokreślona akumulacja w kolejkach liter dead- pozostaje kolejnym elementem, którym należy się zająć. * * Lessons Learned * * Incydent wzmacnia, że adresowanie tylko symptom\ (nasycenie dysku\) bez badania przyczyny akumulacji gwarantuje ponowne wystąpienie problemu. Brak polityki cyklu życia\ (TTL / fresh\) dla liter dead- letter kolejki i brak walidacji wielkości ładunku przed publikacją są dwie centralne luki strukturalne do skorygowania. Ponadto wpis, który oznaczał tę kwestię, został sklasyfikowany jako niski priorytet, co spowodowało opóźnienie o około 38 minut między uruchomieniem wpisu a formalnym otwarciem incydentu - niedopuszczalny okres dla krytycznej degradacji służby.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 lipca 2026 12:51 UTCidentified

   Drogi kliencie, Zidentyfikowaliśmy niestabilność w zakresie możliwości weryfikacji tożsamości, wywołując błąd w niewielkiej części wniosków IDCloud. Nasz zespół inżynieryjny jest już zmobilizowany do diagnozy i pracuje nad zidentyfikowaniem przyczyny, aby jak najszybciej znormalizować usługę. W tym czasie zespół techniczny przeprowadza szczegółową analizę w naszej warstwie danych w celu złagodzenia wpływu. Potwierdzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

2. 13 lipca 2026 13:06 UTCmonitoring

   Drogi kliencie, Nasz zespół inżynieryjny zidentyfikował i wdrożył działania mające na celu rozwiązanie problemu niestabilności zdolności weryfikacji tożsamości, która powodowała błąd w niewielkiej części wniosków IDCloud. W tym czasie zespół techniczny prowadzi szczegółową analizę w naszej warstwie danych i nadal monitoruje środowisko. Potwierdzamy, że kolejne aktualizacje zostaną wkrótce przesłane.

3. 13 lipca 2026 13:47 UTCresolved

   Streszczenie i wpływ 13 lipca 2026 roku zidentyfikowaliśmy niestabilność w naszej zdolności weryfikacji tożsamości, generując błędy w minimalnej części wniosków IDCloud, wpływając na wiele przepływów uwierzytelniania. Kwestia ta została wykryta poprzez automatyczne alarmy dostępności około 9: 27 AM BRT, z niewielkim wzrostem błędów już zauważalne od około 8: 00 AM BRT i znaczne pogorszenie począwszy od około 9: 07 AM BRT, osiągając szczytowy wpływ około 9: 49 AM BRT. Przyczyna i rozdzielczość Przyczyna główna została zidentyfikowana jako stopniowa zmiana zastosowana do wewnętrznego elementu uwierzytelniającego, który spowodował niepowodzenie w zatwierdzaniu symbolu sesji. Po potwierdzeniu przyczyny, zespół inżynieryjny odwrócił zmianę i dostępność usług wróciła do normy. Najbardziej krytyczna faza uderzenia trwała około 44 minut. Zaangażowanie i kolejne kroki Inżynieria ocenia udoskonalenia procesu walidacji zmian w celu stopniowego wprowadzania wpływających na kluczowe elementy uwierzytelniania, w tym automatyczne mechanizmy wycofywania w przypadku skoków błędów w trakcie tego typu wprowadzania. Oczekuje się, że kolejny krok będzie przeprowadzany wewnętrznie.

4. 20 lipca 2026 22:47 UTCpostmortem

   # Pośmiertna: Uwierzytelnianie Niestabilność przepływu * * Data incydentu: * * 13 lipca 2026 * * Czas trwania uderzenia: * * ~ 44 minuty Podsumowanie 13 lipca 2026 roku zidentyfikowaliśmy degradację dostępności w przepływach uwierzytelniania platformy. Incydent został spowodowany niekompatybilnością wprowadzoną podczas ciągłego rozmieszczania wewnętrznego komponentu odpowiedzialnego za walidację żetonów bezpieczeństwa. Przyczyna została zdiagnozowana przez nasze zespoły operacyjne i cofnięcie aktualizacji przywrócona stabilność systemu w ciągu kilku minut. # # Impact Degradacja trwała około 44 minut i jednocześnie wpłynęła na wielokrotne przepływy uwierzytelniania na platformie, co doprowadziło do błędu wynoszącego około 0,9% w przypadku usług zwróconych do klienta. W tym okresie niektórzy użytkownicy końcowi doświadczyli niestabilności i widzieli ogólne komunikaty błędów\ (HTTP 500\) podczas próby uwierzytelniania. Chociaż wydarzenie trwało 44 minuty, wahało się między zwiększonym opóźnieniem a niedostępnością. # # Root Cause # Usterka została spowodowana wadą oprogramowania wprowadzoną w aktualizacji elementu walidacji tokena bezpieczeństwa, co doprowadziło do niezgodności między instancjami prowadzącymi różne wersje. Ta niezgodność nie została wykryta w środowiskach testowych, ponieważ wymagała równoczesnego, równoległego wykonania różnych wersji. Ponadto wewnętrzny punkt końcowy zwrócił odpowiedź HTTP na sukces nawet wtedy, gdy walidacja nie powiodła się, co uniemożliwiło automatyczne systemy monitorowania wdrożenia z wykryciem problemu i automatyczne wstrzymanie uruchamiania. # # Resolution Po zidentyfikowaniu przyczyny, zespół on-call dokonał cofnięcia dotkniętego komponentu, natychmiast przywracając dostępność przepływów uwierzytelniania. Incydent został wykryty przez automatyczne alarmy SLO w ciągu kilku minut od rozpoczęcia degradacji, a eskalacja umożliwiła pełną diagnozę i złagodzenie incydentu. Lekcje Poprawimy walidację kompatybilności wersji w rozmieszczaniu toczenia, dostosujemy zachowanie odpowiedzi HTTP wewnętrznych punktów końcowych, aby wywołać automatyczne cofnięcie nieudanego rozmieszczania oraz standaryzujemy obsługę błędów, aby zapobiec zamaskowaniu błędów przed dotarciem do klienta. # # Zobowiązanie do ciągłego doskonalenia Takie zdarzenia wzmacniają nasze zaangażowanie na rzecz ciągłej poprawy niezawodności platformy. Każdy incydent traktujemy jako szansę na uczenie się, przegląd naszych procesów, wzmocnienie mechanizmów wykrywania i zapobiegania oraz ciągłe inwestowanie w bardziej solidne praktyki inżynieryjne. Naszym celem jest dalsze podnoszenie poprzeczki na dostępności i przejrzystości dla wszystkich naszych klientów. Drużyna Unico.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 lipca 2026 16:43 UTCinvestigating

   Obecnie doświadczamy niestabilności zdolności IDCLOUD. Nasz zespół techniczny już bada przyczynę. Dostarczymy aktualizacje, jak tylko pojawi się więcej informacji.

2. 10 lipca 2026 17:12 UTCidentified

   Zidentyfikowaliśmy niestabilność, która może powodować czasowe przestoje lub opóźnienia w niektórych naszych podstawowych API weryfikacji i analizy ryzyka. Usługi powiązane: - Tożsamość i walidacja: Weryfikacja tożsamości, 1: 1 Walidacja, Serpro podobieństwa Powrót - Ryzyko i oszustwo: ocena ryzyka, klasyfikacja ryzyka oszustwa - Dokumentacja i liniowość: Przywracanie i przechwytywanie dokumentów, Litywność Aktualny status i kolejne kroki: Nasz zespół inżynieryjny jest już w pełni zaangażowany i bada przyczynę. Pracujemy aktywnie, aby odizolować zachowanie i przywrócić normalne operacje jak najszybciej.

3. 10 lipca 2026 17:25 UTCmonitoring

   Bieżący stan i kolejne kroki Działania łagodzące zostały z powodzeniem zastosowane, a system jest teraz stabilny. W tym czasie nasz zespół inżynieryjny nadal aktywnie monitoruje wydajność platformy, aby zapewnić ciągłą stabilność i normalne działania. Dziękuję za cierpliwość i zrozumienie podczas tego incydentu. Twoje usługi powinny działać normalnie.

4. 10 lipca 2026 17:57 UTCresolved

   Streszczenie i wpływ Między 1: 21 PM a 2: 16 PM (czas Brasília) w dniu 10 lipca 2026 roku, zidentyfikowaliśmy wahania w dostępności przepływu tworzenia procesów i związanych z nimi podróży, co spowodowało tymczasowy wzrost poziomu błędów niektórych naszych głównych API. - Zakres oddziaływania: Wydarzenie miało wpływ wyłącznie na dostępność niektórych podróży w tym okresie. Klienci, którzy nie doświadczyli wzrostu poziomu błędu w tym okresie, nie mieli wpływu. - Integralność danych: Nie było kompromisu dla integralności lub bezpieczeństwa przetwarzanych informacji. - Łagodzenie: W ciągu kilku minut zastosowano wstępną procedurę, co zatrzymało ilość błędów. Usługa została w pełni znormalizowana o 14: 16, po potwierdzeniu stabilności przez nasze zespoły inżynieryjne i monitorujące. Przyczyna korzenia Incydent został wywołany przez niestabilność w usłudze infrastrukturalnej, a następnie nagłą degradację w inicjalizacji powiązanych komponentów wewnętrznych. Zaangażowanie i kolejne kroki Jesteśmy głęboko zaangażowani w odporność naszej platformy. Działania naprawcze i zapobiegawcze zainicjowane w trakcie incydentu są już monitorowane w celu zmniejszenia ryzyka przyszłych zdarzeń tego rodzaju. - Pośmiertny: Szczegółowy raport techniczny (Pośmiertny) zostanie wkrótce udostępniony, zawierający pełną linię czasową, analizę architektoniczną i długoterminowy plan działania z określonymi terminami. Serdecznie przepraszamy za skutki i niestabilność. Zaufanie naszych klientów jest naszym najwyższym priorytetem, a my ciągle pracujemy nad zapewnieniem doskonałości naszych usług. Z poważaniem, Unico Team

5. 14 lipca 2026 14:08 UTCpostmortem

   / Podsumowanie W dniu 10 lipca 2026 r., między 1: 21 PM a 2: 09 PM\ (czas Brasília\), poziom błędu w procesie tworzenia przepływu osiągnął wartość około 11% przez około 9 minut, przy stałej degradacji dostępności do 2: 09 PM. Incydent został spowodowany niestabilnością komponentu zarządzania konfiguracją infrastruktury, co uniemożliwiło prawidłowe inicjowanie kapsuł usług biometrycznych. Uderzenie zostało wzmocnione przez uprzednio istniejące zachowanie zużycia pamięci\ (które zwiększyło częstotliwość restartowania modułu\) oraz przez skok ruchu, który wywołał tworzenie nowych instancji - z których wszystkie nie były w stanie zainicjować w oknie niestabilności komponentu konfiguracyjnego. Uzasadnienie * * Uderzenie * * Równocześnie wpłynęły na wiele przepływów - w tym tworzenie procesów, uwierzytelnianie, biometria, płatności i operacje wewnętrzne - przy czym błędy rozprzestrzeniały się we wszystkich usługach zależnych od silnika biometrycznego. Przy szczytowym poziomie błędu poziom błędu osiągnął 11%. Liczba dostępnych kapsuł usług biometrycznych spadła do niemal zera w obu klastrach produkcyjnych podczas najbardziej krytycznego okna incydentu. Uzasadnienie * * Root Cause * * Przyczyna źródłowa była związana z możliwością optymalizacji w logice uruchomienia usługi biometrycznej: aplikacja odmówiła wystąpienia, jeśli element zarządzania konfiguracją infrastruktury zwrócił awarię podczas startu, nawet gdy dane buforowane były dostępne do wykorzystania jako awaryjne. Logika ta traktowała przejściową komunikację w taki sam sposób, jak stały błąd konfiguracji, czyniąc pamięć podręczną bezużyteczną dokładnie w chwili, gdy była najbardziej potrzebna. Kiedy element konfiguracyjny stał się niestabilny, każda kapsuła próbująca ponownie uruchomić - czy to z powodu ciśnienia w pamięci, czy autoskalowania - utknęła w pętli awarii, nie mogąc zakończyć procesu inicjalizacji. Uzasadnienie * * Resolution * * Zespół zawierał pierwsze uderzenie, izolując ruch z jednego z dotkniętych elementów, co zatrzymało wzrost błędu w ciągu około 9 minut. Stabilizacja zastosowanego komponentu zarządzania konfiguracją, pozwalającego na normalny powrót kapsuł. W tym samym dniu przygotowano i wdrożono awaryjną naprawę, usuwając restrykcyjną walidację, która zablokowała uruchomienie systemu - zapewniając, że zapasowe obudowy pamięci podręcznej są używane w sposób przejrzysty w podobnych sytuacjach. * * Lessons Learned * * Incydent ujawnił, że mechanizm odporności usługi - zapasowy pamięci podręcznej - istniał w architekturze, ale został zneutralizowany przez logikę startup, która traktowała priorytetowo ścisłą walidację danych nad dostępnością środowiska. Ścieżki startowe dla usług krytycznych muszą być zaprojektowane w taki sposób, aby z wdziękiem rozkładać się, gdy elementy infrastruktury są niestabilne, zapewniając ciągłość działania. * * Zobowiązanie do stabilności i ciągłej poprawy * * Będziemy nadal intensywnie inwestować w solidność naszej infrastruktury, aby zapewnić, że nasze usługi działają konsekwentnie na najwyższym poziomie wydajności, bezpieczeństwa i niezawodności. Drużyna Unico.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

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

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

3. 3 lipca 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 lipca 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 lipca 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 czerwca 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 lipca 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 czerwca 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 czerwca 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 czerwca 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 lipca 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 czerwca 2026 01:24 UTCinvestigating

   Prezado Cliente, Nossa monitoração proativa detectou um comportamento regular no ID Pay e no fluxo de onboarding do ByUnico. Embora a causa exata ainda esteja sobb 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 diagnostico no ambiente para identificar as causas. Em breve retornamos com atraizações.

2. 23 czerwca 2026 01:39 UTCidentified

   Prezado Cliente, Nossa equipe ainda está invedando a causa raiz do problema. Em breve traremos mais aulaizações. Agradecemos a considensão.

3. 23 czerwca 2026 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 atraulizações serão enviadas em breve.

4. 23 czerwca 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 algun dias compartilharemos maiores detalhes através de um Postmorth. 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 czerwca 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 algun dias compartilharemos maiores detalhes através de um Postmorth. 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 lipca 2026 13:58 UTCpostmortem

   / Podsumowanie W dniu 22 czerwca 2026 roku, o godzinie 9: 52 PM\ (Brasília time\), przepływ zapisu dokumentów stał się niedostępny z powodu wyczerpania limitu sekwencyjnego identyfikatora w bazie danych. Od tego momentu wszystkie operacje wprowadzania dokumentów zaczęły zawodzić, kaskadując błędy dla wielu usług zależnych. Incydent trwał około 86 minut. Uzasadnienie * * Uderzenie * * Jednocześnie ucierpiały liczne usługi krytyczne - w tym przepływy na pokładzie, tworzenie procesów, uwierzytelnianie i płatności. W niektórych przepływach dostępność spadła do poziomu poniżej 3%. Klienci mieli wpływ na użytkowników niepowodzenia lub opóźnienia podczas wykonywania operacji, które zależały od zapisywania dokumentów. Uzasadnienie * * Root Cause * * Przyczyna była związana z 32- bitowym identyfikatorem używanym w tabeli dokumentów, która obsługuje około 2,1 miliarda wartości; przy naturalnym wzroście wielkości rekordu w czasie, granica ta została osiągnięta, powodując, że baza danych nie jest już w stanie generować nowych identyfikatorów, więc wszystkie operacje wstawiania zaczęły zawodzić. Ponieważ nie było monitoringu skonfigurowanego do śledzenia bliskości tego limitu, wyczerpanie nastąpiło nagle i bez wcześniejszego ostrzeżenia. Uzasadnienie * * Resolution * * Zespół zidentyfikował przyczynę za około 20 minut. W celu natychmiastowego złagodzenia, sekwencyjny identyfikator został przekonfigurowany w celu wykorzystania ujemnego zakresu tego samego typu danych, uwalniając w przybliżeniu kolejne 2,1 miliarda wartości bez konieczności zmiany struktury bazy danych. Roztwór został zatwierdzony w niższych środowiskach przed zastosowaniem do produkcji. Usługa zaczęła się stabilizować krótko po nałożeniu poprawki i była monitorowana do momentu potwierdzenia pełnej regeneracji. Uzasadnienie * * Lessons Learned * * Incydent podkreśla znaczenie wdrożenia monitorowania sekwencyjnego stosowania identyfikatorów w tabelach wysokiego wolumenu, z wczesnymi alarmami pozwalającymi na traktowanie wyczerpania jako planowanej obsługi technicznej; przyjęcie od początku 8-bajtowych typów identyfikatorów dla tabel o wysokim wolumenie zapisu, w tym tej kontroli w procesach przeglądu schematów; oraz mapowanie i dokumentowanie krytycznych zależności podstawowych usług utrzymywania się, w celu zwiększenia wpływu i priorytetyzowania komunikacji z zainteresowanymi użytkownikami w przyszłości.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 czerwca 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 czerwca 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 czerwca 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 lipca 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 czerwca 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 czerwca 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 czerwca 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 czerwca 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 czerwca 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 czerwca 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 czerwca 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