Istoricul incidentelor Unico

1. 30 august 2026 la 02:35 UTCinvestigating

   Dragă Client, La aproximativ 11:00 PM (BRT) vineri, 29 august 2026, am identificat o instabilitate care afectează crearea procesului în IDCloud. În această perioadă, unele cereri pot eşua sau experimenta mai lent decât de obicei timpii de răspuns. Recunoaştem neplăcerile pe care le-ar putea cauza şi aprecia înţelegerea voastră. O nouă actualizare va fi furnizată în curând. Echipa Unico

2. 30 august 2026 la 02:49 UTCidentified

   Echipa noastră de ingineri a cartografiat originea instabilităţii care afectează crearea procesului în IDCloud. Echipa tehnică a început deja să aplice măsuri corective, inclusiv creșterea resurselor în stratul afectat și monitorizarea continuă a indicatorilor-cheie. Restaurarea serviciului este gestionată cu prioritate maximă și mobilizarea completă a ingineriei. Reamintim că vor fi trimise în curând noi actualizări. Echipa Unico

3. 30 august 2026 la 02:57 UTCmonitoring

   Dragă Client, Echipa noastră de inginerie a efectuat acțiunile corective necesare pentru a rezolva instabilitatea care afectează crearea procesului în IDCloud. Mediul a revenit la stabilitate, cu indicatori de disponibilitate și timp de răspuns restaurat la niveluri normale de operare la 11:48 PM (BRT). Serviciul este disponibil pentru utilizare normală. În acest moment, echipa noastră tehnică rămâne sub monitorizare asistată, supraveghind îndeaproape mediul pentru a asigura o performanță consecventă și pentru a acționa imediat în caz de fluctuație. Apreciem înţelegerea şi reiterăm faptul că în scurt timp vor fi trimise alte informaţii. Echipa Unico

4. 30 august 2026 la 03:15 UTCresolved

   Dragă Client, Rezumat și impact Intre orele 11:00 PM si 11:48 PM (BRT) la 29 august 2026, o pana afectata de proces creatie in IDCloud. În timpul acestei ferestre, unii clienți care utilizează aceste fluxuri au înregistrat eșecuri și au crescut timpul de răspuns, cu propagarea către călătorii dependente, inclusiv autentificarea, captarea documentelor și livrarea notificării. Nu a existat niciun compromis în ceea ce privește integritatea sau securitatea informațiilor prelucrate și nu s-au pierdut date. Indicatorii au revenit la nivele normale de operare la 11:48 PM (BRT), cu normalizare confirmată atât în monitorizarea noastră, cât și pe partea clientului, acoperind crearea și finalizarea procesului. Cauza principală și rezoluția Originea a fost identificată în stratul nostru de date: o rutină internă de întreținere a devenit blocată, iar operațiunile de aplicare au început să stea la coadă până când limita de conectare disponibilă a fost epuizată, reducând capacitatea de procesare. Echipa noastră de inginerie a terminat chirurgical doar rutina blocată, eliberând imediat coada. Conexiunile și capacitatea de procesare au fost restaurate complet, fără modificări de date. Angajamentul şi etapele următoare Echipa noastră de inginerie se va concentra pe trei fronturi: limitarea timpului de așteptare pentru rutinele de întreținere interne, prevenirea rutinelor concomitente de funcționare împotriva aceleiași structuri, și consolidarea rezilienței serviciului la fluctuații în stratul de date. O autopsie detaliată, inclusiv cronologia completă și un plan de acțiune cu termene limită, vor fi împărtășite în scurt timp. Ne cerem sincer scuze pentru impactul asupra operaţiunilor dumneavoastră şi rămânem disponibili prin intermediul canalelor noastre de sprijin. Echipa Unico

Traducere automată din actualizarea oficială a incidentului.

1. 10 august 2026 la 20:26 UTCidentified

   Dragă client, Am detectat un impact asupra unor cereri IDCloud, care afectează capacitatea de alertă comportamentală (IdTrust) și fluxul 1:N. Această instabilitate poate afecta și clienții din Mexic care utilizează această capacitate. Echipa noastră de inginerie este mobilizat pentru a rezolva problema cât mai curând posibil. Vom furniza noi actualizări în curând.

2. 10 august 2026 la 20:29 UTCmonitoring

   Echipa noastră de inginerie a identificat și implementat acțiunile necesare pentru a rezolva instabilitatea în capacitățile afectate de flux IDCloud. În acest moment, echipa tehnică efectuează o analiză detaliată a stratului nostru de date şi continuă să monitorizeze mediul înconjurător. Reamintim că vor fi trimise în curând noi actualizări.

3. 10 august 2026 la 21:01 UTCresolved

   Rezumat și impact În jurul orei 5:08 PM, o alertă automată a detectat o scădere a disponibilității în serviciul de recunoaștere facială (1:N flux), declanșând incidentul. Problema a escaladat rapid și a început să afecteze serviciul de alertă comportamentală și, ulterior, fluxul de creare proces, din cauza timeouts cascading între aceste servicii. Impactul a afectat un subset de clienți care utilizează aceste capacități. Situația a fost raportată ca fiind stabilizată la 5:22 PM, iar indicatorii revin la nivelurile normale. Cauza principală și rezoluția Cauza rădăcină a fost un vârf de trafic generat de un volum de muncă intern, care a trimis un volum ridicat de cereri de recunoaștere facială direct în conducta biometrică, ocolind stratul de margine utilizat de traficul normal al clienților. Acest volum suplimentar a saturat capacitatea bazei de date care susține serviciul de recunoaștere facială. Saturația a cauzat pauzele în acel serviciu, care a în cascadă la serviciul de orchestrare a motorului biometric, apoi la serviciul de alertă comportamentală, și în cele din urmă la fluxul de creare proces folosind aceste capacități. Pentru a rezolva problema, echipa a oprit volumul de muncă responsabil pentru vârful și a crescut capacitatea bazei de date afectate. Aceste acțiuni au atenuat problema, volumul de erori revenind la nivelul aproape zero. Angajamentul şi etapele următoare A fost deschis un post de monitorizare pentru a pune în aplicare o limitare a ratei pentru tipul de volum de muncă intern care a cauzat creșterea, ca măsură preventivă împotriva recurenței. Creșterea capacității pentru baza de date afectată a fost deja efectuată în timpul incidentului în sine.

4. 25 august 2026 la 13:05 UTCpostmortem

   ** Summary ** La 10 august 2026, între 5:08 PM și 5:27 PM \ (ora Brasília\), indicatorul de disponibilitate pentru fluxul de recunoaștere facială 1:N a scăzut sub 95%, cu un impact total de aproximativ 19 minute. Incidentul a fost cauzat de saturarea bazei de date de căutare vectorială utilizată de motorul biometric, rezultat din comportamentul neașteptat în mecanismul de consum al cozii, care a generat un volum de apel de 2,36 ori mai mare decât cel configurat. Încărcătura în exces a atins limita maximă de scalare a bazei de date, cauzând întârzieri în cascadă în cadrul mai multor servicii dependente și afectând 55 de utilizatori cu erori în timpul perioadei. **Impact** Utilizatorii de recunoaștere facială, autentificare și proces de creare fluxurile de la mai mulți clienți a experimentat erori și timeouts în timpul perioadei. Saturaţia bazei de date a fost în cascadă prin orchestrarea biometrică, motor şi servicii de creare a proceselor. Diminuarea a fost realizată prin dezactivarea unui serviciu intern și creșterea limitei maxime de scalare a bazei de date, stabilizarea serviciului la 5:27 PM. **Root Cause** Cauza principală a fost o combinație de factori legați de comportamentul în serviciu și de capacitatea infrastructurii implicate. Serviciul a fost configurat cu o limită de 2 cereri pe secundă, dar mecanismul de consum al cozii s-a comportat neașteptat: mesajele a căror prelucrare a depășit termenul limită de recunoaștere au fost relivrate de coadă fără a anula execuția originală Acest trafic amplificat a ajuns la baza de date fără a trece prin stratul de protecție de margine, care ar limita în mod normal volumul cererii, deoarece calea de rețea utilizată în acest flux nu a trecut prin aceste controale. Baza de date, care funcţionează deja aproape de limita maximă de scalare, nu a fost în măsură să absoarbă sarcina suplimentară **Rezoluţie** Echipa a identificat procesul în cauză ca fiind sursa încărcăturii în câteva minute de la alertă. Procesul a fost dezactivat, iar limita maximă de scalare a bazei de date a crescut de la 100 la 150 de noduri. Cu aceste două acţiuni, serviciul s-a stabilizat la 5:27 PM. ** Lecţii învăţate ** Incidentul a arătat că limitarea ratei aplicate numai pe partea de publicare a mesajelor este insuficientă atunci când consumatorul poate amplifica volumul prin relivrare. De asemenea, trebuie să existe controale ale ratei și ale valutei. În plus, serviciile interne care accesează componente critice prin căi care ocolesc protecția marginilor reprezintă un risc structural .

Traducere automată din actualizarea oficială a incidentului.

1. 31 iulie 2026 la 12:42 UTCinvestigating

   Clienţi Prezados, Identificamos uma stabilidade écnica pontual que afeta atualização do paineel de acompanhamento após o invidio de documentos. Reforçamos que o fluxo de invidio e assinatura está funcionando normalmente: os destinatários continuam recebendo e conseguindo assinar os arquivos. Nu ento, o registro do invidio 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 retabelecer o histórico no paineel o mais breve possível. Pedimos desculpas pelo inconveneniente e manteremos todos informados sobre o progresso. Atenciosamente,

2. 31 iulie 2026 la 13:08 UTCidentified

   Clienţi Prezados, Gostaríamos de atualizar o status sobre a vizualização de documentos no paineel de acompanhamento. O problema foi identificado com sucesso por nossa dope tecnica. No momento, os engenheiros já estão subindo a correção para restabecler a exibição coreta de todos os invidios na interface do remetente. Lembramos que o procesamento, invidio 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 iulie 2026 la 13:20 UTCmonitoring

   Clienţi Prezados, Informamos que a correção para a exibição no paineel de acompanhamento foi aplicada com sucesso. A lista de documente e históricos de invidios 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 enceramento em breve. Atenciosamente,

4. 31 iulie 2026 la 14:06 UTCresolved

   Clienţi Prezados, Informamos que o incidente relacionado à exibição de invidios no paineel de acompanhamento foi oficialmente entrado. Após aplicação da correção e o período de monitoramento, confirmamos que a listagem e o histórico de documentos foram totalmente retabelekidos, e a plataforma opera em completa estabilidade. Agradecemos pela compreensão e pasiência de todos durante o processeo. Atenciosamente,

Traducere automată din actualizarea oficială a incidentului.

1. 29 iulie 2026 la 14:04 UTCresolved

   Rezumat și impact Am dori să vă informăm că incidentul care afectează temporar serviciul de notificare ID Cloud Webhook a fost rezolvat. Perioada de impact: de la 08:32 la 10:05. Impact Platforma: Instabilitatea a fost strict limitată la livrarea notificării Webhook, rezultând o întârziere în distribuirea mesajelor. Nu a existat nici o degradare a platformei principale, nici un defect la motorul de viata, si nici o pierdere de date. Impactul clientului: Problema a afectat o mică parte din clienţi. Clienții care au implementat un flux de votare GET ca o situație de urgență (cădere) nu s-au confruntat cu un timp de repaus sau impact operațional. Cauza principală & Rezoluția Cauza Root: Instabilitatea a fost declanșată de o actualizare caracteristică în mediu. O nepotrivire temporară a permisiunilor de acces între coada de lucru și ruta de destinație a cauzat refuzul cererilor, ceea ce a dus la o întârziere temporară a notificărilor. Acțiune revoluționară: Echipa tehnică a finalizat redirecționarea traficului către noul mediu, restaurând comunicarea corespunzătoare între componente și eliberând backlog-ul Webhooks. Procesarea a revenit la normal, și coada de expediere a fost complet eliminate. Angajamente și pașii următori Stabilitatea serviciilor noastre este cea mai mare prioritate a noastră. Pentru a asigura transparența totală și a preveni recurența, echipa noastră de inginerie se va concentra pe următoarele fronturi: Detailed Postmortem: Va fi elaborat un raport cuprinzător cu o analiză aprofundată a cauzelor profunde și un plan de acțiune preventiv. Îmbunătăţiri ale vizibilităţii: Vom ajusta indicatorii de monitorizare pentru a asigura o mai mare vizibilitate în erorile de comunicare interservicii în timpul scenariilor de tranziție. Ne cerem sincer scuze pentru inconveniente și rămânem disponibili pentru orice clarificări suplimentare. Cu sinceritate, echipa Unico

2. 7 august 2026 la 13:08 UTCpostmortem

   ** Summary ** Pe 29 iulie 2026, între 8:32 AM și 10:05 AM \(Ora Brasília\), serviciul de livrare a webhook a fost degradat timp de aproximativ 1 oră și 33 minute. Incidentul a fost cauzat de o migrare planificată a infrastructurii care a creat o stare de incompatibilitate tranzitorie: după ce rutele interne au fost trecute la noul cluster, serviciul webhook a început să genereze jetoane de autentificare din noul cluster, dar livrările erau încă direcţionate către vechiul cluster care a respins jetoanele cu o eroare de autorizare. Evenimentele pierdute au fost reprocesate la cerere. **Impact** Multiple produse au fost afectate simultan, inclusiv autentificarea, plățile și fluxurile la bordul navei. Utilizatorii clienților care s-au bazat exclusiv pe notificări webhook pentru a-și continua fluxurile de afaceri au suferit întreruperi operaționale în cursul perioadei. Clienţii care au implementat sondajele active ca mecanism de rezervă au avut un impact redus. **Root Cause** Cauza principală a fost identificată în planificarea migrației: procedura nu a cartografiat dependența în lanț a fluxului de webhook Prin migrarea rutelor interne și a rutelor publice în etape separate, a fost creată o fereastră de incompatibilitate în care jetoanele generate de noul grup au fost respinse de politica de autorizare a vechiului grup, care a validat în mod specific identificatorul contului de servicii anterior. Acest scenariu nu a fost identificat în timpul evaluării riscului schimbării, iar niciunul dintre indicatorii actuali de calitate a serviciilor nu a acoperit stratul asincronic de livrare în care eșecul s-a materializat. **Rezoluţie** Echipa a identificat incompatibilitatea simbolică ca fiind sursa eșecurilor și a finalizat migrarea rutelor publice către noul grup, eliminând divergențele. Din acel moment, livrările în curs din coadă au început să se proceseze în mod normal. Impactul a încetat la 10:05 AM, iar traficul pe vechiul grup a ajuns la zero la 10:32 AM. ** Lecţii învăţate ** Incidentul a arătat că migraţiile care implică fluxuri de livrare asincrone în lanţ necesită ca toate rutele care participă la lanţ să fie migrate în mod coordonat, fără ferestre de incompatibilitate între grupuri. Abordarea graduală utilizată, deşi potrivită pentru majoritatea migraţiilor, a creat aici o perioadă de eşec prelungită, care ar fi putut fi evitată cu o tranziţie atomică sau cu o fereastră de tranziţie mult mai scurtă. În plus, lipsa de observabilitate la nivelul de livrare asincronă a fost motivul pentru care incidentul nu a fost detectat pe plan intern Crearea de alerte specifice pentru eșecuri și backlog la acest nivel este cea mai urgentă îmbunătățire de monitorizare identificată.

Traducere automată din actualizarea oficială a incidentului.

1. 24 iulie 2026 la 21:47 UTCinvestigating

   Dragă Client, Investigăm în prezent o instabilitate în Webhooks noastre care afectează latența în furnizarea de date. Echipa noastră de inginerie lucrează activ pentru a rezolva problema cât mai repede posibil. Vom furniza noi actualizări în scurt timp.

2. 24 iulie 2026 la 21:53 UTCmonitoring

   Dragă Client, Echipa noastră de inginerie a identificat și implementat acțiunile necesare pentru a rezolva instabilitatea Webhook care afectează latența de livrare a datelor. În acest moment, echipa tehnică efectuează o analiză detaliată a stratului nostru de date şi continuă să monitorizeze mediul înconjurător. Reamintim că vor fi trimise în curând noi actualizări.

3. 24 iulie 2026 la 22:18 UTCresolved

   Rezumat și impact Incepand de la 6:05 PM (ora Brasília), o instabilitate a avut loc in serviciul Webhook, ceea ce a dus la esecul procesarii evenimentelor si la livrarea notificării pentru operatiunile afectate in aceasta perioada. Cauza principală și rezoluția Incidentul a fost cauzat de o problemă cu un cont comun de servicii utilizat în cadrul mai multor servicii, ceea ce a dus la eșecuri de autentificare. La identificarea cauzei profunde, echipa de inginerie restaurat acreditările necesare și configurația. Operaţiunea normală a fost restabilită complet la ora 6:29 PM (BRT). Angajamentul şi etapele următoare Ca parte a îmbunătățirii continue și a reducerii riscurilor, echipa de inginerie va revizui dependențele de resurse și gestionarea accesului între servicii. Acest lucru va preveni probleme similare de configurare în viitoarele ajustări ale infrastructurii.

4. 3 august 2026 la 20:00 UTCpostmortem

   ** Summary ** La 24 iulie 2026, între orele 6:05 PM și 6:29 PM \(Ora Brasília\), serviciul de creare și livrare webhook a fost indisponibil pentru aproximativ 24 de minute. Incidentul a fost cauzat de pierderea accesului la un cont de servicii de infrastructură în timpul unui proces de dezafectare a resurselor legat de o migrare a unui grup efectuată cu câteva zile înainte. Contul afectat a fost împărțit de mai multe servicii fără ca această dependență să fie documentată, ceea ce a făcut ca serviciul webhook să își piardă capacitatea de autentificare și să înceteze să mai creeze și să mai ofere evenimente. **Impact** Crearea și livrarea de evenimente Webhook a fost întreruptă în cursul perioadei, afectând 18 utilizatori de clienți cu peste 1,550 de erori înregistrate. Impactul s-a produs în cascadă față de alte servicii care depind de același flux de autentificare, cauzând degradarea simultană a diferitelor capacități ale platformei. **Root Cause** Cauza principală a fost identificată în configurația dependenței de servicii. Această dependenţă între servicii nu a fost nici documentată, nici vizibilă în cartografierea dependenţei. Atunci când procesul de dezafectare a eliminat contul ca parte a curățării resurselor serviciului original, nu a existat o validare automată pentru a verifica dacă contul era încă utilizat de alte servicii active. Absenţa acestei protecţii a ţinut dependenţa ascunsă până când eliminarea acesteia a cauzat eşecuri de autentificare pe scară largă. **Rezoluţie** Echipa a identificat rapid contul de servicii instabile ca fiind sursa eșecurilor de autentificare. Contul a fost ajustat manual și aplicat clusterului, restaurând serviciul la 6:29 PM. Durata totală a impactului a fost de aproximativ 24 minute. ** Lecţii învăţate ** Incidentul a expus riscurile configuraţiilor tradiţionale care creează dependenţe ascunse între servicii: o singură schimbare de resurse în timpul întreţinerii planificate a fost suficientă pentru a perturba simultan mai multe servicii. Procesul de dezafectare a resurselor de infrastructură trebuie să includă validarea automată a dependenței înainte de orice modificare.

Traducere automată din actualizarea oficială a incidentului.

1. 21 iulie 2026 la 16:39 UTCidentified

   Dragă client, Investigăm o instabilitate în funcționalitățile IDCloud care afectează fluxurile de autentificare în călătoria de proces, în special impactul Web Journey (fost ByUnico). Echipa noastră de inginerie este mobilizat pentru a rezolva problema cât mai curând posibil. Vom furniza noi actualizări în scurt timp.

2. 21 iulie 2026 la 16:49 UTCmonitoring

   Dragă Client, Echipa noastră de inginerie a identificat și implementat acțiunile necesare pentru a rezolva instabilitatea în capacitățile afectate de flux IDCloud. În acest moment, echipa tehnică efectuează o analiză detaliată a stratului nostru de date şi continuă să monitorizeze mediul înconjurător. Reamintim că vor fi trimise în curând noi actualizări.

3. 21 iulie 2026 la 18:02 UTCresolved

   Rezumat și impact Pornind de la aproximativ 12:44 PM (timpul Brasília) la 21 iulie 2026, o parte din utilizatori în călătoria redusă la bord au experimentat o încărcare mai lentă a ecranelor inițiale în flux. Impactul a fost observat în toate mediile în care se utilizează această călătorie, afectând viteza percepută și, într-o măsură mai mică, capacitatea utilizatorilor de a finaliza procesul în această perioadă. Cauza principală și rezoluția Ancheta este în curs de desfășurare pentru a confirma cauza definitivă a incidentului. Nu a existat nici un impact asupra serverelor, rețelei, sau infrastructurii Ca măsură de izolare, echipa responsabilă a aplicat o ajustare preventivă la 1:39 PM (BRT), iar timpul de încărcare a revenit la normal în câteva minute. Analiza pentru validarea și confirmarea cauzei profunde este încă în curs de desfășurare de către echipa tehnică. Angajamentul şi etapele următoare Ca parte a îmbunătățirii continue a proceselor de răspuns la incidente, echipa se angajează să îmbunătățească fluxul automat de escaladare pentru echipele responsabile, ceea ce face activarea mai directă și mai eficientă din momentul în care se deschide un incident. În plus, monitorizarea vitezei de încărcare va fi consolidată în timpul introducerii unor noi schimbări în această călătorie, cu scopul de a identifica și corecta regresiile potențiale chiar mai rapid, minimizând impactul asupra utilizatorilor în situații similare care merg înainte.

4. 3 august 2026 la 14:01 UTCpostmortem

   ** Summary ** Pe 21 iulie 2026, între 12:44 PM şi 1:43 PM \(Ora Brasília\), indicatorii de performanţă pentru călătoria redusă s-au degradat sever, cu timpul mediu de încărcare jumping de la ~4.8s la ~8.9 şi p95 ajungând la 31.5 secunde. Incidentul a fost cauzat de limitarea ratei aplicate de infrastructura cloud pe conexiunile provenite de la furnizor, ceea ce a împiedicat încărcarea activelor frontend. **Impact** Utilizatorii din 32 de clienti au experimentat sarcini extrem de lente de pagina sau eșecuri complete de încărcare, cu aproximativ 94 de erori de călătorie înregistrate. Erorile "Initializare Timeout" au declanşat atunci când aplicaţia nu reuşeşte să se monteze în decurs de 30 de secunde, ajungând la aproximativ 23 mii de evenimente în timpul perioadei. **Root Cause** Cauza principală a fost identificată în stratul de rețea al infrastructurii: furnizorul CDN consolidează traficul printr-un set limitat de adrese IP de ieșire. Un vârf în noi conexiuni TCP și strângere de mână TLS provenind din aceste IP-uri a declanșat mecanismele de apărare automată a infrastructurii de acoperire a rețelei, care au început conexiunile de limitare a ratei chiar înainte de procesarea HTTP. Deoarece aceste eșecuri au avut loc la stratul de rețea **Rezoluţie** Impactul a încetat odată cu recuperarea naturală a limitării ratei aplicate de infrastructura cloud. Dezactivarea unei componente, iniţial semnalată ca o posibilă cauză, a coincis temporal cu recuperarea, dar ulterior s-a confirmat că nu are legătură cu incidentul. Configurație fix ** Lecţii învăţate ** Incidentul a subliniat faptul că eșecurile la nivelul rețelei dintre CCN și infrastructura cloud sunt invizibile pentru monitorizarea standard a aplicațiilor, creând un punct mort semnificativ. Ca elemente de urmărire, echipa a identificat necesitatea de a implementa remedierile de configurare recomandate de furnizori și de a extinde observabilitatea la nivelul de livrare a activelor pentru a detecta proactiv acest tip de degradare.

Traducere automată din actualizarea oficială a incidentului.

1. 21 iulie 2026 la 14:39 UTCidentified

   Dragă client, Investigăm o instabilitate în capacitățile noastre IDCloud, care afectează procesul de creare și proces de detalii curge. Echipa noastră de inginerie este mobilizat pentru a rezolva problema cât mai curând posibil. Vom furniza noi actualizări în scurt timp.

2. 21 iulie 2026 la 14:46 UTCidentified

   Continuăm să lucrăm la o soluție pentru această problemă.

3. 21 iulie 2026 la 14:50 UTCmonitoring

   Dragă Client, Echipa noastră de inginerie a identificat și implementat acțiunile necesare pentru a rezolva instabilitatea în capacitățile afectate de flux IDCloud. În acest moment, echipa tehnică efectuează o analiză detaliată a stratului nostru de date şi continuă să monitorizeze mediul înconjurător. Reamintim că vor fi trimise în curând noi actualizări.

4. 21 iulie 2026 la 16:00 UTCresolved

   Rezumat și impact Pe 21 iulie 2026, în jurul orei 11:17 AM BRT, a fost detectată o scădere a disponibilității în fluxurile de creare-procesare și proces-query IDCloud. În timpul ferestrei de impact, o parte din clienți au experimentat latență ridicată și eșecuri (timeout) în aceste operațiuni, care s-au propagat prin lanțul de servicii dependente. Impactul efectiv a fost concentrat într-o fereastră de aproximativ 23 de minute. La vârf, indicatorii de eroare și de latență au depășit nivelurile normale de funcționare. Cauza principală și rezoluția Ancheta a indicat degradarea unei baze de date citite (replica) care susține aceste capacități ca origine. Această bază de date a început să arate timpul de execuție a sarcinilor și interogărilor, cu dispute interne care au blocat procesarea și au susținut cererile de citire. Prin urmare, serviciile de mai sus au început să acumuleze temporizări și să declanșeze mecanisme de protecție (ruptoare de circuit), producând efectul de cascadă experimentat de clienți. Angajamentul şi etapele următoare Unico se ocupă de acest incident cu o autopsie detaliată, fiind deja în curs de elaborare, şi va organiza o şedinţă post-incidenţă (PiR) pentru consolidarea acţiunilor preventive. Printre acțiunile întreprinse deja în timpul răspunsului se numără pregătirea de rutine de diagnosticare și întrebări pentru a accelera identificarea disputei în acest strat de bază de date și îmbunătățirea vizibilității bazelor de date implicate. Acțiunile preventive detaliate vor fi împărtășite la autopsie. Ne reafirmăm angajamentul față de stabilitatea și fiabilitatea platformei și ne cerem scuze pentru inconvenientele cauzate în perioada instabilității. Echipa Unico.

5. 28 iulie 2026 la 12:10 UTCpostmortem

   ** Summary ** Pe 21 iulie 2026, între 11:41 și 11:43 AM \(Ora Brasília\), fluxul de creare a procesului a devenit indisponibil, cu rata principală de eroare de serviciu ajungând la 42% și p99 latență la 15.75 secunde. Incidentul a fost cauzat de saturarea reproducerii bazei de date biometrie: baza de date de memorie nu a mai fost în măsură să servească setului de date cel mai frecvent accesat, cauzând în mod normal interogări rapide pentru a reveni la citirea discului, creând o spirală auto-împiedicătoare a sesiunilor acumulate și creșterea latenței. **Impact** Utilizatorii procesului de creare, autentificare, și fluxuri de plăți între mai mulți clienți au primit erori și timeouts în timpul perioadei. Baza de date primară a rămas intactă de-a lungul incidentului. **Root Cause** Cauza principală a fost saturarea: întrebările utilizate în fluxul de autentificare efectuau scanări extinse pe tabele critice din cauza indicilor lipsă. În condiții normale, acest comportament a fost tolerat de infrastructura bazei de date. Când capacitatea de memorie a atins limita și nu a mai putut păstra cele mai accesate date în cache, fiecare citire a început să aducă date de pe disc, ceea ce face costul de fiecare interogare exponențial mai mare. Acest efect de colaps abrupt În plus, toate traficul citit pentru fluxul critic a fost concentrat pe o singură replică, fără distribuție sau cale alternativă, eliminând orice rezistență la acest tip de degradare. **Rezoluţie** Baza de date a recuperat în mod natural ca sesiunile acumulate drenate, fără intervenție manuală. Echipa a escaladat la echipa de baze de date și a monitorizat stabilizarea serviciului. Incidentul a fost închis după confirmarea că operaţiunea normală a fost restabilită. ** Lecţii învăţate ** Incidentul a relevat lacune structurale în stratul bazei de date: indicii lipsă privind interogările critice și concentrarea tuturor traficului citit pe o singură replică fără o rută alternativă. Ca follow-up-uri, echipa a prioritizat crearea indicilor lipsă, distribuirea de trafic citit peste replici, și construirea de runbook-uri de diagnosticare pentru a accelera răspunsul în incidente viitoare de natură similară.

Traducere automată din actualizarea oficială a incidentului.

1. 20 iulie 2026 la 12:33 UTCidentified

   Dragă Client, Am identificat o instabilitate în unele dintre capacitățile noastre IDCloud, care afectează GetSelfie, crearea de proces, și detalii de proces curge pentru Web Journey (fost ByUnico). Fluxurile API Journey (ByClient) nu au fost afectate. Echipa noastră de inginerie este mobilizat pentru a rezolva problema cât mai curând posibil. Vom urmări în scurt timp cu actualizări suplimentare.

2. 20 iulie 2026 la 12:35 UTCidentified

   Continuăm să lucrăm la o soluție pentru această problemă.

3. 20 iulie 2026 la 12:39 UTCmonitoring

   Dragă Client, Echipa noastră de inginerie a identificat și implementat acțiunile necesare pentru a rezolva instabilitatea în capacitățile afectate de flux IDCloud. În acest moment, echipa tehnică efectuează o analiză detaliată a stratului nostru de date şi continuă să monitorizeze mediul înconjurător. Reamintim că vor fi trimise în curând noi actualizări.

4. 20 iulie 2026 la 13:22 UTCresolved

   Rezumat și impact Am identificat o instabilitate care afectează fluxurile de captare și vizualizare a procesului, precum și autentificarea, pentru Web Journey, cu impact între 09:07 și 09:21 (BRT). Impactul a atins o parte din clienti folosind acest flux; API Journey nu a fost afectat. Cauza principală și rezoluția Cauza rădăcină este legată de o schimbare de configurație aplicată în producție, care a cauzat o sarcină crescută pe o componentă de bază de date internă. Această sarcină crescută a ridicat latență și erori într-un strat de integrare, care la rândul său a declanșat un mecanism de protecție și a întrerupt temporar fluxurile Web Journey. Echipa de inginerie a dat înapoi schimbarea configurației pentru a atenua problema, iar situația s-a normalizat la scurt timp după aceea. Angajamentul şi etapele următoare Echipa de ingineri continuă să monitorizeze mediul înconjurător după reluarea modificărilor făcute. O autopsie detaliată va fi împărţită de echipa noastră în următoarele zile. Ne cerem scuze pentru deranj. Echipa Unico!

5. 4 august 2026 la 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.

Traducere automată din actualizarea oficială a incidentului.

1. 16 iulie 2026 la 14:02 UTCinvestigating

   Dragă Client, Investigăm o instabilitate în sistemul nostru de autentificare pentru portalurile Unico People și evaluăm, de asemenea, problemele din serviciul nostru de mesagerie care afectează clienții IDCloud. Echipa noastră de inginerie este mobilizat pentru a rezolva problema cât mai curând posibil. Vă vom oferi actualizări în scurt timp.

2. 16 iulie 2026 la 14:08 UTCmonitoring

   Dragă Client, Echipa noastră a identificat problema și a luat măsuri pentru a rezolva incidentul. Am experimentat o instabilitate în sistemul nostru de autentificare pentru portalurile Unico People, precum și probleme în serviciul nostru de mesagerie care afectează clienții în fluxul IDCloud, pentru SMS și livrare de e-mail. Echipa noastră de inginerie rămâne mobilizată, monitorizând mediul pentru a se asigura că funcționează în continuare în mod corespunzător.

3. 16 iulie 2026 la 15:28 UTCresolved

   Rezumat și impact La 10:51 AM pe 07/16/2026, o problemă a fost identificată în serviciul de autentificare pe portalul de admitere Unico People și în mesagerie, care a afectat livrarea de link-uri SMS și e-mail către Unico People și clienții IDCloud, precum și autentificarea clientului B2C pe portalul de admitere Unico People. Impactul s-a limitat la aceste două fluxuri și nu a afectat călătoria critică principală a produsului. Incidentul a durat aproximativ 30 de minute până la rezolvarea completă. Cauza principală și rezoluția Cauza rădăcină a fost identificată ca fiind presiunea de stocare pe un nod al clusterului de mesagerie, care a atins un prag critic al discului, degradând procesarea cozilor responsabile pentru transmiterea și autentificarea mesajelor. Echipa de inginerie a crescut capacitatea de stocare a clusterului la aproximativ 10:59 AM, care a permis cozilor și indicatorilor de monitorizare să normalizeze în câteva minute. Mediul a fost monitorizat până la recuperarea completă a fost confirmată, iar incidentul a fost închis la 11:20 AM. Angajamentul şi etapele următoare Echipa de inginerie va revizui criteriile de escaladare și de prioritizare a alertelor pentru acest tip de degradare, deoarece alertele au identificat corect problema, dar fluxul automat de escaladare către echipa responsabilă poate fi îmbunătățit. O autopsie detaliată este în curs de pregătire și va fi împărtășit în zilele următoare.

4. 3 august 2026 la 12:14 UTCpostmortem

   ** Summary ** Pe 16 iulie 2026, între 10:12 AM și 11:10 AM \(Ora Brasília\), serviciul de mesagerie și autentificare a fost degradat timp de aproximativ 58 de minute. Cauza a fost saturarea discului pe unul dintre nodurile din clusterul cozii de mesaje, care, la atingerea limitei configurate, a blocat automat toți editorii, cauzând un backlog de până la 33 mii de mesaje în coadă. Impactul a afectat furnizarea de linkuri de autentificare prin SMS și e-mail, precum și fluxul de autentificare al utilizatorului final pe portalul de admitere Unico People. **Impact** Utilizatorii care așteptau linkuri de autentificare prin SMS sau e-mail nu le-au primit în perioada respectivă. Utilizatorii finali ai unui produs de administrare a persoanelor care încearcă să se autentifice pe portalul de admitere nu au putut accesa serviciul. Impactul a fost conţinut după extinderea discului. **Root Cause** Cauza principală a fost identificată în fluxul de procesare a mesajelor: încărcăturile utile excesiv de mari Deoarece au fost respinşi în mod determinist la fiecare încercare, aceste mesaje au fost direcţionate către cozi dead-letter după epuizarea tuturor retries. Aceste cozi nu au avut nici o politică de expirare sau de curățare automată, determinând mesajele să se acumuleze pe termen nelimitat și să consume progresiv spațiul discului grupului. **Rezoluţie** Discul clusterului a fost extins la 500 GB pe nod, ceea ce a normalizat imediat cozile și clusterele. Serviciul a revenit la normal la 11:10 AM. Cauza de rădăcină structurală ** Lecţii învăţate ** Incidentul consolidează faptul că abordarea doar a simptomului \ (saturație de disc\) fără a investiga cauza principală a acumulării garantează recurența problemei. Lipsa unei politici privind ciclul de viață \ (TTL/expirare\) pentru cozile cu litere moarte și lipsa validării dimensiunii sarcinii înainte de publicare sunt cele două lacune structurale centrale care trebuie corectate. În plus, alerta care a semnalat problema a fost clasificată ca fiind o prioritate redusă, ceea ce a cauzat o întârziere de aproximativ 38 de minute între declanșarea semnalării și deschiderea oficială a incidentului.

Traducere automată din actualizarea oficială a incidentului.

1. 13 iulie 2026 la 12:51 UTCidentified

   Dragă Client, Am identificat o instabilitate în capacitatea de verificare a identității, generând o eroare într-o mică parte din cererile IDCloud. Echipa noastră de inginerie este deja mobilizat pentru diagnostic și de lucru pentru a identifica cauza rădăcină în scopul de a normaliza serviciul cât mai curând posibil. În acest moment, echipa tehnică efectuează analize detaliate în stratul nostru de date pentru a atenua impactul. Noi întărim faptul că noi actualizări vor fi trimise în curând.

2. 13 iulie 2026 la 13:06 UTCmonitoring

   Dragă Client, Echipa noastră de inginerie a identificat şi implementat acţiunile de rezolvare a instabilităţii capacităţii de verificare a identităţii care genera o eroare într-o mică parte din cererile IDCloud. În acest moment, echipa tehnică efectuează analize detaliate în stratul nostru de date și continuă să monitorizeze mediul înconjurător. Noi întărim faptul că noi actualizări vor fi trimise în curând.

3. 13 iulie 2026 la 13:47 UTCresolved

   Rezumat și impact La 13 iulie 2026, am identificat o instabilitate în capacitatea noastră de verificare a identității, generând erori pe o parte minimă a cererilor IDCloud, afectând fluxuri multiple de autentificare. Problema a fost detectată prin alerte de disponibilitate automată în jurul valorii de 9:27 AM BRT, cu o ușoară creștere a erorilor deja vizibile de la aproximativ 8:00 AM BRT și o agravare semnificativă începând cu aproximativ 9:07 AM BRT, ajungând la impactul maxim în jurul valorii de 9:49 AM BRT. Cauza principală și rezoluția Cauza principală a fost identificată ca o modificare treptată aplicată unei componente de autentificare internă, care a cauzat o eșec în validarea semnăturii sesiunii. Odată ce cauza principală a fost confirmată, echipa de inginerie a revenit schimbarea, iar disponibilitatea serviciilor a revenit la normal. Faza cea mai critică a impactului a durat aproximativ 44 de minute. Angajamentul şi etapele următoare Ingineria evaluează îmbunătățirile procesului de validare a schimbării în ceea ce privește introducerea treptată a componentelor critice de autentificare, inclusiv mecanismele automate de răsturnare în cazul unor vârfuri de eroare în timpul acestui tip de lansare. O autopsie detaliată este de așteptat să fie împărtășită intern ca un pas următor.

4. 20 iulie 2026 la 22:47 UTCpostmortem

   Postmortem: Instabilitatea fluxului de autentificare ** Data incidentului:** 13 iulie 2026 ** Durata impactului:** ~44 minute ## Rezumat La 13 iulie 2026, am identificat o degradare a disponibilității în fluxurile de autentificare ale platformei. Incidentul a fost cauzat de o incompatibilitate introdusă în timpul implementării unei componente interne responsabile cu validarea jetoanelor de securitate. Cauza a fost diagnosticată de echipele noastre de operaţiuni, iar actualizarea a restabilit stabilitatea sistemului în câteva minute. ## Impact Degradarea a durat aproximativ 44 de minute și a afectat simultan mai multe fluxuri de autentificare de pe platformă, ceea ce a dus la o rată de eroare de aproximativ 0,9% în serviciile orientate spre clienți. În această perioadă, unii utilizatori finali s-au confruntat cu instabilitate și au văzut mesaje generice de eroare \ (HTTP 500\) atunci când au încercat să se autentifice. Deşi evenimentul a durat 44 de minute, acesta a fluctuat între creşterea latenţei şi a neputinţei. ## Root Cause Eșecul a fost cauzat de un defect software introdus într-o actualizare a componentei de validare a jetoanelor de securitate, ceea ce a dus la incompatibilitate între cazurile care rulează versiuni diferite. Această incompatibilitate nu a fost detectată în mediile de testare, deoarece a necesitat executarea simultană și paralelă a diferitelor versiuni. În plus, obiectivul intern a returnat un răspuns de succes HTTP chiar și atunci când validarea a eșuat, ceea ce a împiedicat sistemele automatizate de monitorizare a implementării să detecteze problema și să oprească automat introducerea. ## Resolution Odată ce cauza a fost identificată, echipa de gardă a executat o revenire a componentei afectate, restabilind imediat disponibilitatea fluxurilor de autentificare. Incidentul a fost detectat prin alerte automate SLO în câteva minute de la începerea degradării, iar escaladarea a permis diagnosticarea completă și atenuarea incidentului. Lecţii învăţate Vom îmbunătăţi validarea compatibilităţii versiunii în desfăşurarea la rulare, vom ajusta comportamentul de răspuns HTTP al obiectivelor interne pentru a declanşa o revenire automată a implementării defectuoase şi vom standardiza manipularea erorilor pentru a preveni mascarea eşecurilor înainte de a ajunge la client. ## Angajamentul faţă de îmbunătăţirea continuă Incidente ca acesta ne consolidează angajamentul de a îmbunătăți permanent fiabilitatea platformei. Tratăm fiecare incident ca pe o oportunitate de învăţare, revizuim procesele noastre, întărim mecanismele de detectare şi prevenire şi investim continuu în practici inginereşti mai solide. Scopul nostru este de a menține barul privind disponibilitatea și transparența pentru toți clienții noștri. Echipa Unico.

Traducere automată din actualizarea oficială a incidentului.

1. 10 iulie 2026 la 16:43 UTCinvestigating

   În prezent ne confruntăm cu instabilitate în capacitățile IDCLOUD. Echipa noastră tehnică investighează deja cauza principală. Vom oferi actualizări de îndată ce mai multe informații devin disponibile.

2. 10 iulie 2026 la 17:12 UTCidentified

   Am identificat o instabilitate care ar putea cauza o scădere temporară a timpului sau latență în unele dintre testele noastre de bază și analiza riscurilor. Servicii afectate: - Identitate & Validare: Verificarea identitatii, 1:1 Validare, Returnare similaritate Serpro - Risc & Fraudă: Scorul riscului, clasificarea riscului de fraudă - Documentaţie & Libilitate: Refolosire şi Captură documentară, Libilitate Starea actuală și etapele următoare: Echipa noastră de inginerie este deja pe deplin angajată și investighează cauza rădăcină. Lucrăm activ pentru a izola comportamentul și a restabili operațiunile normale cât mai repede posibil.

3. 10 iulie 2026 la 17:25 UTCmonitoring

   Starea curentă și etapele următoare Acțiunile de atenuare au fost aplicate cu succes, iar sistemul este acum stabil. În acest moment, echipa noastră de Inginerie continuă să monitorizeze în mod activ performanța platformei pentru a asigura stabilitatea continuă și operațiunile normale. Vă mulțumim pentru răbdare și înțelegere în timpul acestui incident. Serviciile tale ar trebui să funcţioneze normal.

4. 10 iulie 2026 la 17:57 UTCresolved

   Rezumat și impact Între orele 1:21 PM și 2:16 PM (Ora Brasília) la 10 iulie 2026, am identificat o fluctuație a disponibilității fluxului de creare a procesului și a călătoriilor conexe, rezultând o creștere temporară a ratei de eroare a unora dintre principalele noastre API. - Domeniul de aplicare al impactului: Evenimentul a afectat exclusiv disponibilitatea anumitor călătorii în acest interval. Clienții care nu au experimentat o creștere a ratei de eroare în această perioadă nu au fost afectați. - Integritatea datelor: Nu a existat niciun compromis în ceea ce privește integritatea sau securitatea informațiilor prelucrate. - Diminuarea: O primă analiză a fost aplicată în câteva minute, stopând volumul erorilor. Serviciul a fost complet normalizat la ora 2:16 PM, urmând confirmarea stabilităţii echipelor noastre de Inginerie şi Monitorizare. Cauza rădăcină Incidentul a fost declanșat de instabilitatea unui serviciu de infrastructură, urmată de o degradare bruscă a inițializării componentelor interne conexe. Angajamentul şi etapele următoare Suntem profund dedicaţi rezistenţei platformei noastre. Acțiunile corective și preventive inițiate în timpul incidentului sunt deja monitorizate pentru a atenua riscul unor evenimente viitoare de acest tip. - Postmortem: Un raport tehnic detaliat (Postmortem) va fi împărtășit în curând, conținând calendarul complet, analiza arhitecturală și un plan de acțiune pe termen lung cu termene definite. Ne cerem sincer scuze pentru impactul şi instabilitatea cauzate. Încrederea clienților noștri este prioritatea noastră cea mai mare și continuăm să lucrăm continuu pentru a asigura excelența serviciilor noastre. Cu sinceritate, echipa Unico

5. 14 iulie 2026 la 14:08 UTCpostmortem

   ** Summary ** Pe 10 iulie 2026, între 1:21 PM și 2:09 PM \(Ora Brasília\), rata de eroare în procesul de creare a fluxului a atins un vârf de aproximativ 11% pentru aproximativ 9 minute, cu degradarea continuă a disponibilității până la 2:09 PM. Incidentul a fost cauzat de o instabilitate în componenta de gestionare a configurației infrastructurii, care a împiedicat păstăile de servicii biometrice să inițializeze corect. Impactul a fost amplificat de un comportament pre-existent de consum al memoriei \[care a crescut frecvența pod reporneşte\) şi de un vârf de trafic care a declanşat crearea de noi instanţe **Impact** Fluxurile multiple au fost afectate simultan La vârf, rata de eroare a atins 11%. Numărul de capsule de serviciu biometric disponibile a scăzut la aproape zero în ambele grupuri de producție în timpul celei mai critice ferestre a incidentului. **Root Cause** Cauza rădăcină a fost legată de o oportunitate de optimizare în logica de pornire a serviciului biometric: aplicația a refuzat să apară dacă componenta de gestionare a configurației infrastructurii returna un eșec în timpul boot-ului, chiar și atunci când datele cache erau disponibile pentru a fi utilizate ca rezervă. Această logică a tratat o întrerupere temporară a comunicării în același mod ca o eroare permanentă de configurare, făcând cache-ul de rezervă inutilizabil exact în momentul în care a fost nevoie cel mai mult. Când componenta de configurare a devenit instabilă, fiecare pod încearcă să repornească **Rezoluţie** Echipa a conţinut impactul iniţial prin izolarea traficului de una dintre componentele afectate, care a oprit pironul de eroare în aproximativ 9 minute. Stabilizarea componentei de gestionare a configurației urmată, permițând capsulelor să revină în mod normal. O fix de urgență a fost pregătită și implementată în aceeași zi, eliminând validarea restrictivă care a blocat startup-ul ** Lecţii învăţate ** Incidentul a arătat că mecanismul de reziliență al serviciului Căile de pornire pentru serviciile critice trebuie concepute astfel încât să se degradeze cu graţie atunci când componentele de infrastructură de sprijin sunt instabile, asigurând continuitatea operaţională. **Comiterea la stabilitate și îmbunătățirea continuă** Vom continua să investim puternic în soliditatea infrastructurii noastre pentru a ne asigura că serviciile noastre funcționează în mod constant la cele mai înalte niveluri de eficiență, securitate și fiabilitate. Echipa Unico.

Traducere automată din actualizarea oficială a incidentului.

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

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

3. 3 iulie 2026 la 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 iulie 2026 la 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 iulie 2026 la 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 iunie 2026 la 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 iulie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iulie 2026 la 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 iunie 2026 la 01:24 UTCinvestigating

   Prezado Cliente, Nossa monitoração proativa detectou um comportamento neregulat no ID Pay e no fluxo de la bording do ByUnico. Embora a causa exata ainda esteja sob investigigação, isso pode se manifestar como lentão ou intermitência no serviço. A equipe de tecnologia está executando todos os procesimentos de diagnóstico no ambiente paraidentificar as causas. Em breve retornamos com atualizações.

2. 23 iunie 2026 la 01:39 UTCidentified

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

3. 23 iunie 2026 la 01:53 UTCidentified

   Prezado Cliente, Informamos que nossa equipeidentifcou a causa da stabilidade e está ativamente trabalhando na aplicação da solução. Seguimos empenhados em retabelecer o serviço o mais rapidamente possível e manteremos você informado sobre a evolução. Novas atualizações serão invidiadas em breve.

4. 23 iunie 2026 la 02:18 UTCmonitoring

   Prezado Cliente, Nossa dotaeidentificou as causas do problema e realizou as ações para que este incidente foss 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. Atenţie, Equipe Unico!

5. 23 iunie 2026 la 02:41 UTCresolved

   Prezado Cliente, Nossa dotaeidentificou as causas do problema e realizou as ações para que este incidente foss 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. Atenţie, Equipe Unico!

6. 14 iulie 2026 la 13:58 UTCpostmortem

   ** Summary ** La 22 iunie 2026, la ora 9:52 PM \(Ora Brasília\), fluxul de economisire a documentelor a devenit indisponibil din cauza epuizării unei limite de identificare secvențială în baza de date. Din acel moment, toate operaţiunile de inserţie a documentelor au început să eşueze, cazând erori la mai multe servicii dependente. Incidentul a durat aproximativ 86 de minute. **Impact** Multiple servicii critice au fost afectate simultan, inclusiv fluxurile la bord, crearea de procese, autentificarea și plățile. În unele fluxuri, disponibilitatea a scăzut sub 3%. Clienții au avut utilizatori afectate de eșecuri sau întârzieri atunci când încearcă operațiuni care depind de salvarea documentelor. **Root Cause** Cauza principală a fost legată de tipul de identificator de 32 de biți utilizat în tabelul de documente, care susține valori de aproximativ 2,1 miliarde; odată cu creșterea naturală a volumului record în timp, această limită a fost atinsă, ceea ce a făcut baza de date să nu mai poată genera noi identificatori, astfel încât toate operațiunile de inserție au început să eșueze. Întrucât nu a existat nicio monitorizare configurată pentru a urmări apropierea de această limită, epuizarea a avut loc brusc şi fără avertizare prealabilă. **Rezoluţie** Echipa a identificat cauza în aproximativ 20 de minute. Ca o atenuare imediată, identificatorul secvențial a fost reconfigurat pentru a utiliza gama negativă a aceluiași tip de date, eliberând aproximativ alte 2,1 miliarde de valori fără a necesita modificări structurale în baza de date. Soluția a fost validată în medii inferioare înainte de a fi aplicată producției. Serviciul a început să se stabilizeze la scurt timp după ce fix a fost aplicat și a fost monitorizat până la recuperarea completă a fost confirmată. ** Lecţii învăţate ** Incidentul subliniază importanţa punerii în aplicare a monitorizării utilizării identificatorului secvenţial în tabelele de volum mare, cu alerte timpurii care permit gestionarea epuizării ca întreţinere planificată; adoptarea de la început a unor tipuri de identificatori de 8 octeţi pentru tabele cu volum mare de scriere, inclusiv acest control în procesele de revizuire a schemei; cartografierea şi documentarea dependenţelor critice ale serviciilor de persistenţă de bază, pentru a măsura impactul şi prioritiza comunicarea cu utilizatorii afectaţi mai rapid în incidentele viitoare.

Traducere automată din actualizarea oficială a incidentului.

1. 19 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iulie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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