Unico driftsforstyrrelser

1. 30. august 2026 kl. 02.35 UTCinvestigating

   Kære kunde. Ved omkring 11: 00 PM (BRT) fredag, 29 august 2026, vi identificeret en ustabilitet påvirker proces skabelse i IDCloud. I denne periode kan nogle anmodninger mislykkes eller opleves langsommere end normalt. Vi anerkender den ulejlighed, dette kan forårsage og værdsætter din forståelse. En ny opdatering vil blive leveret inden længe. Unico Team

2. 30. august 2026 kl. 02.49 UTCidentified

   Vores ingeniørhold har kortlagt oprindelsen til den ustabilitet, der påvirker processkabelsen i IDCloud. Det tekniske team er allerede begyndt at anvende korrigerende foranstaltninger, herunder skalering af ressourcerne i det berørte lag og løbende overvågning af nøgleindikatorer. Genoprettelse af tjenesten håndteres med topprioritet og fuld engineering. Vi gentager, at der snart vil blive sendt yderligere opdateringer. Unico Team

3. 30. august 2026 kl. 02.57 UTCmonitoring

   Kære kunde. Vores ingeniørhold har udført de korrigerende handlinger, der er nødvendige for at løse den ustabilitet, der påvirker processkabelsen i IDCloud. Miljøet er vendt tilbage til stabilitet, med tilgængelighed og responstid indikatorer genoprettet til normale driftsniveauer fra 11: 48 PM (BRT). Tjenesten er tilgængelig til normal brug. På nuværende tidspunkt er vores tekniske team fortsat under assisteret overvågning, og holder nøje øje med miljøet for at sikre en konsekvent præstation og for at handle øjeblikkeligt i tilfælde af udsving. Vi sætter pris på din forståelse og gentager, at yderligere opdateringer vil blive sendt snart. Unico Team

4. 30. august 2026 kl. 03.15 UTCresolved

   Kære kunde. Sammenfatning og virkning Mellem 11: 00 og 11: 48 PM (BRT) den 29 august 2026, en afbrydelse påvirket proces skabelse i IDCloud. I dette vindue oplevede nogle kunder, der brugte disse strømme, svigt og øgede svartider, med formering til afhængige rejser, herunder autentificering, dokumentregistrering og underretningslevering. Der var intet kompromis med integriteten eller sikkerheden af de behandlede oplysninger, og ingen data gik tabt. Indikatorer vendt tilbage til normale driftsniveauer på 11: 48 PM (BRT), med normalisering bekræftet både i vores overvågning og på kundens side, der dækker proces skabelse og afslutning. Rodårsag og opløsning Oprindelsen blev identificeret i vores datalag: en intern vedligeholdelse rutine blev hængende, og applikation operationer begyndte kø bag det indtil den tilgængelige tilslutningsgrænse var opbrugt, reducere behandlingskapacitet. Vores ingeniørhold stoppede kun rutinen og frigav straks køen. Forbindelser og behandlingskapacitet blev fuldt restaureret uden dataændringer. Forpligtelse og næste skridt Vores ingeniørhold vil fokusere på tre fronter: at begrænse ventetiden for interne vedligeholdelsesrutiner, forhindre samtidige rutiner i at køre mod den samme struktur, og styrke service modstandsdygtighed over for udsving i datalag. En detaljeret post mortem, herunder hele tidsplanen og en handlingsplan med frister, vil blive delt om kort tid. Vi undskylder oprigtigt for virkningen på dine operationer og forbliver tilgængelige via vores supportkanaler. Unico Team

Automatisk oversat fra den officielle hændelsesopdatering.

1. 10. august 2026 kl. 20.26 UTCidentified

   Kære kunde. Vi har opdaget en indvirkning på nogle IDCloud anmodninger, påvirker Behavior Alert (IDTrust) kapacitet og 1: N flow. Denne ustabilitet kan også påvirke kunder i Mexico, der bruger denne evne. Vores ingeniørhold er mobiliseret til at løse problemet så hurtigt som muligt. Vi vil levere nye opdateringer om kort tid.

2. 10. august 2026 kl. 20.29 UTCmonitoring

   Vores ingeniørhold har identificeret og gennemført de nødvendige foranstaltninger til at løse ustabiliteten i de berørte IDCloud flow kapaciteter. På nuværende tidspunkt foretager det tekniske team en detaljeret analyse af vores datalag og overvåger fortsat miljøet. Vi gentager, at der snart vil blive sendt yderligere opdateringer.

3. 10. august 2026 kl. 21.01 UTCresolved

   Sammenfatning og virkning Omkring 5: 08 PM, en automatiseret alarm opdaget en tilgængelighed fald i ansigtsgenkendelse service (1: N flow), udløser hændelsen. Spørgsmålet eskalerede hurtigt og begyndte at påvirke adfærd alarmering service og efterfølgende processen skabelse flow, på grund af cascading timeouts mellem disse tjenester. Virkningen påvirkede en delmængde af klienter ved hjælp af disse kapaciteter. Situationen blev rapporteret som stabiliseret kl 5: 22, med målinger vender tilbage til normale niveauer. Rodårsag og opløsning Den grundlæggende årsag var en trafik spike genereret af en intern arbejdsbyrde, som sendte en stor mængde af ansigtsgenkendelse anmodninger direkte ind i den biometriske rørledning, uden at passere kant lag anvendes af normal kundetrafik. Dette ekstra volumen mættede kapaciteten i databasen, der understøtter ansigtsgenkendelsestjenesten. Mætningen forårsagede timeouts i den tjeneste, som kaskadedes til den biometriske motor orkestrering service, derefter til adfærd alarmering service, og endelig til processen skabelse flow ved hjælp af disse kapaciteter. For at løse problemet stoppede holdet den arbejdsbyrde, der var ansvarlig for spiken, og øgede kapaciteten i den berørte database. Disse handlinger mildnede problemet, med fejlmængde vender tilbage til næsten nul niveauer. Forpligtelse og næste skridt Et opfølgningspunkt blev åbnet for at gennemføre hastighedsbegrænsning for den type intern arbejdsbyrde, der forårsagede spiken, som en forebyggende foranstaltning mod gentagelse. Kapacitetsforøgelsen for den berørte database blev allerede gennemført under selve hændelsen.

4. 25. august 2026 kl. 13.05 UTCpostmortem

   * * Oversigt * * Den 10. august 2026, mellem 5: 08 PM og 5: 27 PM\ (Brasília tid\), tilgængeligheden indikator for 1: N ansigtsgenkendelse flow faldt under 95%, med en samlet effekt på ca. 19 minutter. Hændelsen var forårsaget af mætning af vektorsøgningsdatabasen, der anvendes af den biometriske motor, som skyldes uventet adfærd i køens forbrugsmekanisme, som genererede et opkald volumen 2,36 gange højere end konfigureret. Den overskydende belastning nåede databasens maksimale skaleringsgrænse, hvilket forårsager cascading timeouts på tværs af flere afhængige tjenester og påvirker 55 klientbrugere med fejl i perioden. * * Indvirkning * * Brugere af ansigtsgenkendelse, autentificering og processkabelse strømme fra flere kunder oplevet fejl og timeouts i perioden. Databasen mætning cascaded gennem biometrisk orkestrering, motor, og proces skabelse tjenester. Mitigation blev udført ved at deaktivere en intern tjeneste og øge databasens maksimale skaleringsgrænse, stabilisere tjenesten kl. 17.27. * * Rodårsag * * Den grundlæggende årsag var en kombination af faktorer relateret til service adfærd og kapaciteten af infrastrukturen involveret. Tjenesten blev konfigureret med en grænse på 2 anmodninger i sekundet, men køens forbrugsmekanisme opførte sig uventet: meddelelser, hvis behandling oversteg anerkendelsesfristen, blev genleveret af køen uden at annullere den oprindelige udførelse - gør 938 arbejdsemner til 2.217 effektive opkald\ (~ 8.4 RPS\). Denne øgede trafik nåede frem til databasen uden at passere gennem kantbeskyttelseslaget, hvilket normalt ville begrænse efterspørgslen volumen, da den netværksvej, der anvendes i denne strøm, ikke gik gennem disse kontroller. Databasen, der allerede opererer tæt på sin maksimale skaleringsgrænse, var ikke i stand til at absorbere den ekstra belastning - dens CPU nåede 88%, mens skalering op til det konfigurerede loft på 100 knudepunkter - og forespørgsel latency sprang fra ~ 3 sekunder til ~ 18,75 sekunder på p90, sprede timeouts over hele kæden af afhængige tjenester. * * Opløsning * * Holdet identificerede den pågældende proces som kilden til belastningen inden for få minutter efter indberetningen. Processen var deaktiveret, og databasens maksimale skaleringsgrænse blev øget fra 100 til 150 knudepunkter. Med disse to handlinger stabiliserede tjenesten sig kl. 17.27. * * Lektioner lært * * Hændelsen viste, at hastighedsbegrænsning kun anvendes på meddelelsens publiceringsside er utilstrækkelig, når forbrugeren kan forstærke volumen ved genlevering. Der skal også være kontrol med priser og valuta på forbrugssiden. Derudover udgør interne tjenester, der får adgang til kritiske komponenter gennem stier, der omgår kantbeskyttelse, en strukturel risiko - enhver intern kunde kan generere ukontrolleret belastning af delt infrastruktur.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. juli 2026 kl. 12.42 UTCinvestigating

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

2. 31. juli 2026 kl. 13.08 UTCidentified

   Prezados clientes Gostaríamos de atualizar o status sobre a visualização de documentos no painel de acompanhamento. O problema foi identificado com suceso 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 rementente. Lemramos que o procesamento, envio e assinatura dos documentos continuam operando normalmente. Volataremos com uma nova atualização assim que a correção for concluída e entrarmos na fase de monitoramento. Atenciosamente,

3. 31. juli 2026 kl. 13.20 UTCmonitoring

   Prezados clientes Informamos que a correção para a exibição no painel de acompanhamento foi aplicada com suceso. En liste 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 exilidade total do serviço. Agradecemos a paciência e traremos a confirmação do encerramento em breve. Atenciosamente,

4. 31. juli 2026 kl. 14.06 UTCresolved

   Prezados clientes Informamos que o incidente relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após a aplicação da correção e o período de monitoramento, confirmamos que a listagem e o histórico de documentos foram totalmente restabelecidos, e a plataforma opera em completa estabilidade. Agradecemos pela beginensão e paciência de todos durante o processo. Atenciosamente,

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. juli 2026 kl. 14.04 UTCresolved

   Sammendrag og virkning Vi vil gerne informere dig om, at hændelsen midlertidigt påvirker ID Cloud Webhook notification service er blevet løst. Anslagsperiode: fra 08: 32 til 10: 05. Platform Indvirkning: Den ustabilitet var strengt begrænset til Webhook anmeldelse levering, hvilket resulterer i en forsinkelse i meddelelse distribution. Der var ingen nedbrydning af hovedplatformen, ingen svigt i løsenet motor, og ingen tab af data. Kundeeffekt: Problemet berørte en lille del af kunderne. Klienter, der har gennemført et GET-afstemningsflow som en nødsituation (fallback) oplevede ingen nedetid eller operationel indvirkning. Rodårsag & opløsning Rodårsag: Ustabiliteten blev udløst af en funktionsopdatering i miljøet. Et midlertidigt mismatch i adgangstilladelser mellem opgavekøen og destinationsruten medførte, at anmodninger blev afvist, hvilket førte til en midlertidig forsinkelse af meddelelser. Resolutiv handling: Den tekniske team afsluttet trafik omdirigering til det nye miljø, genoprette ordentlig kommunikation mellem komponenter og frigive backlog af Webkrogs. Forarbejdningen er blevet normal igen, og forsendelseskøen er blevet helt ryddet. Forpligtelse & næste skridt Vores tjenesters stabilitet er vores højeste prioritet. For at sikre total gennemsigtighed og forhindre gentagelse, vil vores ingeniørhold fokusere på følgende fronter: Detaljeret Postmortem: Der vil blive udarbejdet en omfattende rapport med en dybdegående analyse af årsagerne og en forebyggende handlingsplan. Observationsforbedringer: Vi vil justere målinger for at sikre større synlighed i interservice kommunikationsfejl i overgangsscenarier. Vi beklager dybt ulejligheden og står til rådighed for yderligere præciseringer. Med venlig hilsen, Unico Team

2. 7. august 2026 kl. 13.08 UTCpostmortem

   * * Oversigt * * Den 29. juli 2026, mellem 8: 32 og 10: 05 AM\ (Brasília tid\), webhook levering service blev nedbrudt i ca. 1 time og 33 minutter. Hændelsen var forårsaget af en planlagt infrastrukturmigration, der skabte en forbigående uforenelighed stat: efter interne ruter blev skiftet til den nye klynge, webhook tjenesten begyndte at generere autentificering tokens fra den nye klynge, men leverancer blev stadig rettet til den gamle klynge - som afviste tokens med en godkendelse fejl. Tabte begivenheder blev genbehandlet efter anmodning. * * Indvirkning * * Flere produkter blev påvirket samtidigt - herunder autentificering, betalinger, og on-boarding strømme. Brugere af kunder, der udelukkende baserede sig på webhook-meddelelser for at fortsætte deres forretningsstrømme, oplevede operationelle afbrydelser i perioden. Klienter, der havde gennemført aktiv meningsmåling som en fallback mekanisme oplevede reduceret effekt. * * Rodårsag * * Den grundlæggende årsag blev identificeret i migrationsplanlægningen: proceduren kortlagde ikke den kædede afhængighed af webhook flow - hvor den interne rute skaber en asynkron opgave, der igen kalder den offentlige rute for levering. Ved at migrere de interne ruter og de offentlige ruter i separate trin blev der skabt et uforenelighedsvindue, hvor tokens genereret af den nye klynge blev afvist af den gamle klynges tilladelsespolitik, som specifikt validerede den tidligere servicekontoidentifikator. Dette scenario blev ikke identificeret under forandringens risikovurdering, og ingen af de eksisterende indikatorer for servicekvalitet dækkede det asynkrone leveringslag, hvor fejlen opstod. * * Opløsning * * Holdet identificerede den symbolske uforenelighed som kilden til fiaskoerne og afsluttede migreringen af de offentlige ruter til den nye klynge og eliminerede divergensen. Fra dette tidspunkt begyndte de verserende leverancer i køen normalt at forarbejde. Virkningen ophørte kl. 10.05, og trafikken på den gamle klynge nåede nul kl. 10.32. * * Lektioner lært * * Hændelsen viste, at vandringer, der involverer kædede asynkron leveringsstrømme, kræver, at alle ruter, der deltager i kæden - interne og offentlige - migreres på en koordineret måde, uden uforenelighed vinduer mellem klynger. Den gradvise tilgang, der anvendes, mens egnet til de fleste vandringer, skabt en langvarig fiasko periode her, der kunne have været undgået med en atomare overgang eller en meget kortere overgangsvindue. Derudover var manglen på observerbarhed på asynkron levering lag grunden til hændelsen ikke blev opdaget internt - eksisterende indikatorer målt kun begivenhed accept, ikke faktisk levering. Oprettelse af særlige advarsler for fejl og forsinkelser på dette lag er den mest presserende overvågning forbedring identificeret.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 24. juli 2026 kl. 21.47 UTCinvestigating

   Kære kunde. Vi er i øjeblikket ved at undersøge en ustabilitet i vores Webkrogs, der påvirker latency i data levering. Vores ingeniørhold arbejder aktivt på at løse problemet så hurtigt som muligt. Vi vil levere yderligere opdateringer om kort tid.

2. 24. juli 2026 kl. 21.53 UTCmonitoring

   Kære kunde. Vores ingeniørhold har identificeret og gennemført de nødvendige foranstaltninger til at løse Webhook ustabilitet påvirker data levering latency. På nuværende tidspunkt foretager det tekniske team en detaljeret analyse af vores datalag og overvåger fortsat miljøet. Vi gentager, at der snart vil blive sendt yderligere opdateringer.

3. 24. juli 2026 kl. 22.18 UTCresolved

   Sammenfatning og virkning Startende på 6: 05 PM (Brasília tid), opstod en ustabilitet i Webhook service, hvilket fører til fiasko i tilfælde behandling og anmeldelse levering for berørte operationer i denne periode. Rodårsag og opløsning Hændelsen var forårsaget af et problem med en delt Service-konto, der anvendes på tværs af flere tjenester, hvilket resulterer i autentificering fejl. Ved at identificere roden årsag, ingeniørholdet restaureret de krævede legitimation og konfiguration. Normal drift blev genetableret kl. 18.29 (BRT). Forpligtelse og næste skridt Som led i løbende forbedringer og risikoreduktion vil ingeniørholdet gennemgå ressourceafhængigheder og adgangsstyring på tværs af tjenester. Dette vil forhindre lignende konfigurationsspørgsmål i fremtidige infrastrukturtilpasninger.

4. 3. august 2026 kl. 20.00 UTCpostmortem

   * * Oversigt * * Den 24. juli 2026, mellem 6: 05 og 6: 29 PM\ (Brasília tid\), webhook skabelse og levering service var ikke tilgængelig i ca 24 minutter. Hændelsen skyldtes tabet af adgang til en infrastrukturkonto under en ressourcenedlukningsproces i forbindelse med en klyngemigration, der blev foretaget dage tidligere. Den berørte konto blev delt af flere tjenester, uden at denne afhængighed blev dokumenteret, hvilket fik webhook-tjenesten til at miste sin autentificeringsevne og stoppe med at skabe og levere begivenheder. * * Indvirkning * * Webhook begivenhed skabelse og levering blev afbrudt i løbet af perioden, påvirker 18 klientbrugere med mere end 1.550 fejl registreret. Virkningen cascaded til andre tjenester, der afhang af den samme autentificering flow, forårsager samtidig nedbrydning på tværs af forskellige platform kapaciteter. * * Rodårsag * * Grundårsagen blev identificeret i serviceafhængighedskonfigurationen. Denne afhængighed på tværs af tjenestegrenene blev hverken dokumenteret eller synlig i nogen form for afhængighedsregistrering. Da nedlukningsprocessen fjernede kontoen som en del af den oprindelige tjenestes ressourceoprydning, var der ingen automatisk validering til at kontrollere, om kontoen stadig blev brugt af andre aktive tjenester. Fraværet af denne garanti holdt afhængigheden skjult, indtil den blev fjernet forårsagede omfattende autentificeringsfejl. * * Opløsning * * Holdet hurtigt identificeret den ustabile service konto som kilden til autentificering fejl. Kontoen blev manuelt justeret og anvendt på klyngen og genoprettede tjenesten kl. 18.29. Den samlede virkningsvarighed var ca. 24 minutter. * * Lektioner lært * * Hændelsen afslørede risikoen for nedarvede konfigurationer, der skaber skjulte afhængigheder mellem tjenester: en enkelt ressource ændring under planlagt vedligeholdelse var nok til at forstyrre flere tjenester samtidigt. Infrastrukturressourcenedlukningsprocessen skal omfatte automatisk validering af afhængighed, før der sker ændringer.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. juli 2026 kl. 16.39 UTCidentified

   Kære kunde. Vi er ved at undersøge en ustabilitet i IDCloud funktioner, der påvirker autentificering strømme i processen rejse, specielt påvirke Web Journey (tidligere ByUnico). Vores ingeniørhold er mobiliseret til at løse problemet så hurtigt som muligt. Vi vil levere yderligere opdateringer om kort tid.

2. 21. juli 2026 kl. 16.49 UTCmonitoring

   Kære kunde. Vores ingeniørhold har identificeret og gennemført de nødvendige foranstaltninger til at løse ustabiliteten i de berørte IDCloud flow kapaciteter. På nuværende tidspunkt foretager det tekniske team en detaljeret analyse af vores datalag og overvåger fortsat miljøet. Vi gentager, at der snart vil blive sendt yderligere opdateringer.

3. 21. juli 2026 kl. 18.02 UTCresolved

   Sammenfatning og virkning Fra omkring 12: 44 PM (Brasília tid) den 21. juli 2026, en del af brugerne i den reducerede on-boarding rejse oplevede langsommere belastning af de oprindelige skærme i strømmen. Virkningen blev observeret i alle miljøer, hvor denne rejse blev brugt, hvilket påvirkede den opfattede hastighed og i mindre grad brugernes evne til at fuldføre processen i denne periode. Rodårsag og opløsning Undersøgelsen er i gang for at bekræfte den endelige årsag til hændelsen. Der var ingen indvirkning på servere, netværk eller infrastruktur - problemet blev bekræftet at være isoleret til on-screen oplevelse på brugerens enhed. Som en indeslutningsforanstaltning anvendte det ansvarlige hold en forebyggende justering kl. 1.39 (BRT), og lasttiden blev normal igen inden for få minutter. Analysen for at validere og bekræfte den grundlæggende årsag er stadig ved at blive gennemført af det tekniske team. Forpligtelse og næste skridt Som led i den løbende forbedring af hændelsesreaktionsprocesser forpligter teamet sig til at øge den automatiske eskaleringsstrøm for ansvarlige hold, hvilket gør aktiveringen endnu mere direkte og effektiv fra det øjeblik en hændelse åbnes. Derudover, loading- hastighed overvågning vil blive styrket under udrulningen af nye ændringer til denne rejse, med det mål at identificere og korrigere potentielle regressioner endnu hurtigere, minimere virkningen for brugere i lignende situationer går fremad.

4. 3. august 2026 kl. 14.01 UTCpostmortem

   * * Oversigt * * Den 21. juli 2026, mellem 12: 44 PM og 1: 43 PM\ (Brasília tid\), side belastning præstationsindikatorer for den reducerede rejse nedbrudt alvorligt, med gennemsnitlig belastning tid hoppe fra ~ 4,8 til ~ 8,9 s og p95 når 31.5 sekunder. Hændelsen var forårsaget af hastighedsbegrænsning anvendt af cloud infrastruktur på forbindelser, der stammer fra udbyderen, som forhindrede frontend aktiver fra lastning. * * Indvirkning * * Brugere fra 32 kunder oplevede ekstremt langsomme sidebelastninger eller komplette lastfejl, med ca. 94 rejsefejl registreret. "Initialisering Timeout" fejl - udløst, når programmet undlader at montere inden for 30 sekunder - nåede omkring 23 tusinde forekomster i perioden. * * Rodårsag * * Den grundlæggende årsag blev identificeret i infrastrukturens netlag: CDN-udbyderen konsoliderer trafikken gennem et begrænset sæt udgående IP-adresser. En spike i nye TCP-forbindelser og TLS håndtryk, der stammer fra disse IP 'er udløste cloud-infrastrukturens automatiske network- lag forsvarsmekanismer, som begyndte rate- begrænsende forbindelser, selv før HTTP-behandling. Fordi disse fejl opstod på netværket lag - før HTTP behandling - de ikke vises i standard anmodning logs, hvilket gør problemet usynlige for konventionel overvågning og betydeligt komplicere diagnosen. * * Opløsning * * Virkningen ophørte med den naturlige genopretning af den hastighedsbegrænsning, som skyinfrastrukturen anvender. Deaktivering af en komponent, oprindeligt markeret som en mulig årsag, faldt tidsmæssigt sammen med genopretningen, men blev senere bekræftet at være ikke relateret til hændelsen. Konfigurationsrettelser - som muliggør HTTP Keep- Alive med en forlænget timeout og tilføjelse af en tilladelsesregel for CDN-IP 'er i kantbeskyttelseslaget - blev identificeret som opfølgningselementer af de involverede udbyderes supporthold. * * Lektioner lært * * Hændelsen fremhævede, at fejl på netværkslaget mellem CDN og cloud-infrastrukturen er usynlige for standard programovervågning, hvilket skaber en betydelig blind plet. Som opfølgning elementer, holdet identificerede behovet for at gennemføre de konfigurationsrettelser anbefales af udbyderne og at udvide observerbarhed på aktiv levering lag til proaktivt at opdage denne type nedbrydning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. juli 2026 kl. 14.39 UTCidentified

   Kære kunde. Vi undersøger en ustabilitet i vores IDCloud kapaciteter, påvirker processen skabelse og proces detaljer strømme. Vores ingeniørhold er mobiliseret til at løse problemet så hurtigt som muligt. Vi vil give yderligere opdateringer om kort tid.

2. 21. juli 2026 kl. 14.46 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

3. 21. juli 2026 kl. 14.50 UTCmonitoring

   Kære kunde. Vores ingeniørhold har identificeret og gennemført de nødvendige foranstaltninger til at løse ustabiliteten i de berørte IDCloud flow kapaciteter. På nuværende tidspunkt foretager det tekniske team en detaljeret analyse af vores datalag og overvåger fortsat miljøet. Vi gentager, at der snart vil blive sendt yderligere opdateringer.

4. 21. juli 2026 kl. 16.00 UTCresolved

   Sammenfatning og virkning Den 21. juli 2026, på omkring 11: 17 AM BRT, et fald i tilgængeligheden blev opdaget i IDCloud create- proces og proces- forespørgsel strømme. Under slagvinduet oplevede en del af kunderne forhøjet latency og svigt (timeouts) i disse operationer, som formerede sig gennem kæden af afhængige tjenester. Den effektive effekt var koncentreret i et vindue på ca. 23 minutter. På toppen, fejl og latency indikatorer var over normale driftsniveauer. Rodårsag og opløsning Undersøgelsen pegede på nedbrydningen af en læsedatabase (replika), der understøtter disse kapaciteter som oprindelse. Denne database begyndte at vise øget belastning og forespørgsel udførelsestid, med intern påstand, der standsede behandling og sikkerhedskopieret læse anmodninger. Som følge heraf begyndte de ovennævnte tjenester at akkumulere timeouts og udløse beskyttelsesmekanismer (kredsløbsafbrydere), hvilket frembragte den kaskadevirkning, kunderne oplevede. Forpligtelse og næste skridt Unico håndterer denne hændelse med en detaljeret post mortem, der allerede er under udarbejdelse, og vil holde et møde efter hændelse gennemgang (PiR) for at konsolidere forebyggende foranstaltninger. Blandt de opfølgning, der allerede er rejst under reaktionen, er forberedelse af diagnostiske rutiner og forespørgsler for at fremskynde identifikation af striden i dette databaselag, og forbedret observerbarhed over de involverede databaser. De detaljerede forebyggende foranstaltninger vil blive delt efter slagtning. Vi bekræfter vores engagement i platformens stabilitet og pålidelighed og undskylder den ulejlighed, der er opstået i ustabile perioder. Unico Team.

5. 28. juli 2026 kl. 12.10 UTCpostmortem

   * * Oversigt * * Den 21. juli 2026, mellem 11: 41 og 11: 43 AM\ (Brasília tid\), processen skabelse flow blev utilgængelig, med den vigtigste service fejlrate nå 42% og p99 latency på 15,75 sekunder. Hændelsen var forårsaget af mætning på biometri database læse replika: databasen hukommelse pulje var ikke længere i stand til at tjene de hyppigst tilgængelige datasæt, forårsager normalt hurtige forespørgsler til at falde tilbage til disk læser, skabe en selvforstærkende spiral af akkumulerede sessioner og stigende latency. * * Indvirkning * * Brugere af processen oprettelse, autentificering og betalinger strømme på tværs af flere kunder modtaget fejl og timeouts i løbet af perioden. Den primære database forblev intakt under hele hændelsen - fejlen blev isoleret til den læste replika. * * Rodårsag * * Den grundlæggende årsag var mætning: forespørgsler, der anvendes i autentificering flow udførte omfattende scanninger på kritiske tabeller på grund af manglende indekser. Under normale forhold blev denne adfærd tolereret af databasen infrastruktur. Når hukommelseskapaciteten nåede sin grænse og kunne ikke længere holde de mest tilgængelige data i cache, hver læse begyndte at hente data fra disk, hvilket gør omkostningerne ved hver forespørgsel eksponentielt højere. Denne pludselige kollaps virkning - hvor gradvis nedbrydning giver plads til en udbredt fiasko - blev selvforstærkende, da sessioner akkumuleret venter på svar og interne database ressource striden øget. Desuden var al læsetrafik for den kritiske strøm koncentreret på en enkelt replika uden fordeling eller alternativ rute, hvilket eliminerede enhver modstandsdygtighed over for denne type nedbrydning. * * Opløsning * * Databasen genvundet naturligt som de akkumulerede sessioner drænet, kræver ingen manuel intervention. Holdet eskalerede til databasen team og overvåget service stabilisering. Hændelsen blev afsluttet efter bekræftelse af, at normal drift var blevet genoprettet. * * Lektioner lært * * Hændelsen afslørede strukturelle huller i databaselaget: manglende indekser på kritiske forespørgsler og koncentration af al læsetrafik på en enkelt kopi uden alternativ rute. Som followups, holdet prioriterede at skabe de manglende indekser, distribuere læse trafik på tværs af kopier, og bygge diagnostiske runbooks til at fremskynde reaktion i fremtidige hændelser af lignende karakter.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. juli 2026 kl. 12.33 UTCidentified

   Kære kunde. Vi har identificeret en ustabilitet i nogle af vores IDCloud kapaciteter, påvirker GetSelfie, proces skabelse, og proces detaljer strømme til Web Journey (tidligere ByUnico). API Journey (ByClient) strømme blev ikke påvirket. Vores ingeniørhold er mobiliseret til at løse problemet så hurtigt som muligt. Vi vil snart følge op med yderligere opdateringer.

2. 20. juli 2026 kl. 12.35 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

3. 20. juli 2026 kl. 12.39 UTCmonitoring

   Kære kunde. Vores ingeniørhold har identificeret og gennemført de nødvendige foranstaltninger til at løse ustabiliteten i de berørte IDCloud flow kapaciteter. På nuværende tidspunkt foretager det tekniske team en detaljeret analyse af vores datalag og overvåger fortsat miljøet. Vi gentager, at der snart vil blive sendt yderligere opdateringer.

4. 20. juli 2026 kl. 13.22 UTCresolved

   Sammenfatning og virkning Vi identificerede en ustabilitet påvirker processen opsamling og visualisering strømme, samt godkendelse, for Web Journey, med indvirkning mellem 09: 07 og 09: 21 (BRT). Virkningen nåede en del af kunderne ved hjælp af dette flow; API Journey blev ikke påvirket. Rodårsag og opløsning Den grundlæggende årsag er knyttet til en konfigurationsændring anvendt i produktionen, som forårsagede øget belastning på en intern databasekomponent. Denne øgede belastning hævede latency og fejl i et integrationslag, som igen udløste en beskyttende mekanisme og midlertidigt afbrød Web Journey strømme. Ingeniørholdet rullede tilbage konfigurationsændringen for at afbøde problemet, og situationen normaliseret kort tid efter. Forpligtelse og næste skridt Teknikerne fortsætter med at overvåge miljøet efter tilbagegangen af de foretagne ændringer. En detaljeret post mortem vil blive delt af vores team i de kommende dage. Vi undskylder ulejligheden. Unico Team!

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

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. juli 2026 kl. 14.02 UTCinvestigating

   Kære kunde. Vi undersøger en ustabilitet i vores autentificeringssystem for Unico People portaler og er også at vurdere spørgsmål i vores messaging service påvirker IDCloud kunder. Vores ingeniørhold er mobiliseret til at løse problemet så hurtigt som muligt. Vi vil levere opdateringer inden længe.

2. 16. juli 2026 kl. 14.08 UTCmonitoring

   Kære kunde. Vores team identificerede problemet og tog skridt til at løse hændelsen. Vi oplevede en ustabilitet i vores autentificeringssystem for Unico People portaler, samt problemer i vores messaging service påvirker kunder i IDCloud flow, for SMS og e-mail levering. Vores ingeniørhold er stadig mobiliseret og overvåger miljøet.

3. 16. juli 2026 kl. 15.28 UTCresolved

   Sammenfatning og virkning kl 10: 51 AM på 07 / 16 / 2026, et problem blev identificeret i autentification service på Unico People entry portal og i beskeder, som påvirkede levering af SMS og e-mail links til Unico People og IDCloud klienter, samt B2C klient autentificering på Unico People entry portal. Virkningen var begrænset til disse to strømme og påvirkede ikke produktets centrale kritiske rejse. Hændelsen varede cirka 30 minutter indtil fuld opløsning. Rodårsag og opløsning Rodårsagen blev identificeret som lagertryk på en node af messaging klyngen, som nåede en kritisk disktærskel, og nedværdigede behandlingen af køer med ansvar for meddelelse levering og autentificering. Ingeniørholdet øgede klyngens lagerkapacitet omkring kl. 10.59, hvilket gjorde det muligt for køer og overvågningsindikatorer at normalisere sig inden for få minutter. Miljøet blev overvåget indtil fuld helbredelse blev bekræftet, og hændelsen blev lukket kl 11: 20. Forpligtelse og næste skridt Teknikholdet vil gennemgå alarmeskalering og prioriteringskriterier for denne type nedbrydning, da indberetningerne korrekt identificerede problemet, men den automatiske eskalering af det ansvarlige team kan forbedres. En detaljeret post mortem er under forberedelse og vil blive delt i de kommende dage.

4. 3. august 2026 kl. 12.14 UTCpostmortem

   * * Oversigt * * Den 16. juli 2026, mellem 10: 12 og 11: 10 AM\ (Brasília tid\), messaging og autentificering service blev nedbrudt i ca 58 minutter. Årsagen var diskmætning på et af knudepunkterne i brevkøens klynge, som efter at have nået den indstillede grænse automatisk blokerede alle udgivere, hvilket forårsagede en forsinkelse på op til 33 tusinde beskeder i køen. Virkningen påvirkede leveringen af autentificering links via SMS og e-mail, samt slutbrugeren autentificering flow på Unico People adgangsportal. * * Indvirkning * * Brugere, der venter på autentificering links via SMS eller e-mail ikke modtage dem i perioden. Slutbrugere af et produkt til håndtering af personer, der forsøgte at autentificere på adgangsportalen, var også ude af stand til at få adgang til tjenesten. Virkningen blev holdt nede efter klyngens disk blev udvidet. * * Rodårsag * * Den grundlæggende årsag blev identificeret i meddelelsesbehandlingsstrømmen: alt for store nyttelaster - genereret af en revisionskomponent, der indeholdt unødvendige data - oversteg den størrelse, der accepteres af meddelelseskøen. Da de blev deterministisk afvist på hvert forsøg, blev disse meddelelser sendt til dead- letter køer efter udmattelse alle reles. Disse køer havde ingen udløb eller automatisk oprydning politik, der forårsager meddelelser til at akkumulere på ubestemt tid og gradvist forbruge klyngens diskplads. * * Opløsning * * Klyngens disk blev udvidet til 500 GB pr. knude, som straks normaliserede køerne og klyngemetrikkerne. Tjenesten blev normal kl. 11.10. Den strukturelle årsag - den ubestemte akkumulation i dødbrevskøerne - er fortsat en opfølgning, der skal behandles. * * Lektioner lært * * Hændelsen styrker, at adressering kun symptom\ (disk mætning\) uden at undersøge den grundlæggende årsag til akkumulering garanterer gentagelse af problemet. Manglen på en livscykluspolitik\ (TTL / udløb\) for dødbrevskøer og manglen på validering af nyttelast før udgivelse er de to centrale strukturelle mangler, der skal rettes. Desuden blev den indberetning, der markerede spørgsmålet, klassificeret som lav prioritet, hvilket forårsagede en forsinkelse på ca. 38 minutter mellem den indberetning, der udløses, og den formelle åbning af hændelsen - et uacceptabelt interval for en kritisk forringelse af tjenesten.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. juli 2026 kl. 12.51 UTCidentified

   Kære klient. Vi har identificeret en ustabilitet i identitetskontrolkapaciteten, hvilket skaber en fejl i en lille del af IDCloud anmodninger. Vores ingeniørhold er allerede mobiliseret til diagnose og arbejder på at identificere den grundlæggende årsag for at normalisere tjenesten så hurtigt som muligt. På nuværende tidspunkt, er det tekniske team udfører detaljeret analyse i vores data lag for at afbøde virkningen. Vi understreger, at der snart vil blive sendt yderligere opdateringer.

2. 13. juli 2026 kl. 13.06 UTCmonitoring

   Kære klient. Vores ingeniørteam har identificeret og implementeret de foranstaltninger, der skal løse den ustabilitet i identitetsverifikationskapaciteten, der skabte en fejl i en lille del af IDCloud anmodninger. På nuværende tidspunkt udfører det tekniske team en detaljeret analyse i vores datalag og overvåger fortsat miljøet. Vi understreger, at der snart vil blive sendt yderligere opdateringer.

3. 13. juli 2026 kl. 13.47 UTCresolved

   Sammenfatning og virkning Den 13. juli 2026 identificerede vi en ustabilitet i vores identitetskontrol kapacitet, genererer fejl på en minimal del af IDCloud anmodninger, påvirker flere autentificering strømme. Spørgsmålet blev opdaget gennem automatiserede tilgængelighed advarsler omkring 9: 27 AM BRT, med en lille stigning i fejl allerede mærkbar fra omkring 8: 00 AM BRT og en betydelig forværring starter omkring 9: 07 AM BRT, når spidseffekt omkring 9: 49 AM BRT. Rodårsag og opløsning Den grundlæggende årsag blev identificeret som en gradvis ændring anvendt på en intern autentificering komponent, som forårsagede en fejl i session token signatur validering. Når roden årsag blev bekræftet, ingeniørholdet vendt tilbage ændringen, og service tilgængelighed tilbage til normal. Den mest kritiske fase af virkningen varede omkring 44 minutter. Forpligtelse og næste skridt Engineering er at evaluere forbedringer af forandringsvalideringsprocessen for gradvise udrulninger, der påvirker kritiske autentifikationskomponenter, herunder automatiske udrulningsmekanismer i tilfælde af fejlstigninger under denne type udrulning. En detaljeret post mortem forventes at blive delt internt som et næste skridt.

4. 20. juli 2026 kl. 22.47 UTCpostmortem

   "Postmortem: Authentication Flow Instable * * hændelsesdato: * * 13. juli 2026 * * Effektvarighed: * * ~ 44 minutter # # Summary Den 13. juli 2026 identificerede vi en forringelse af tilgængeligheden i platformens autentificeringsstrømme. Hændelsen skyldtes en uforenelighed, der blev indført under en rullende implementering af en intern komponent, der er ansvarlig for validering af sikkerhedstokens. Årsagen blev diagnosticeret af vores operationer hold, og rullende tilbage opdateringen genoprettet systemets stabilitet inden for få minutter. # Impact Nedbrydningen varede ca. 44 minutter og påvirkede samtidig flere autentificeringsstrømme på platformen, hvilket resulterede i en fejlfrekvens på ca. 0,9% i kundeorienterede tjenester. I denne periode, nogle slutbrugere oplevede ustabilitet og så generiske fejlmeddelelser\ (HTTP 500\), når de forsøger at autentificere. Selvom begivenheden varede 44 minutter, svingede den mellem øget latency og manglende tilgængelighed. # Root Cause Fejlen skyldtes en softwaredefekt, der blev introduceret i en opdatering af sikkerhedstegnet validering komponent, hvilket resulterede i uforenelighed mellem tilfælde kører forskellige versioner. Denne uforenelighed blev ikke påvist i testmiljøer, da det krævede samtidig, parallel udførelse af forskellige versioner. Derudover returnerede det interne endpoint en HTTP-succesrespons, selv når valideringen mislykkedes, hvilket forhindrede automatiske implementeringsovervågningssystemer i at opdage problemet og automatisk stoppe udrulningen. # Opløsning Når årsagen blev identificeret, on- call team udført en rollback af den berørte komponent, straks genoprette tilgængeligheden af autentificering strømme. Hændelsen blev opdaget ved automatiske SLO-indberetninger inden for få minutter efter nedbrydningen starter, og eskalering muliggjorde fuld diagnose og afbødning af hændelsen. # Lektioner lært Vi vil forbedre version- kompatibilitet validering i rullende implementeringer, justere HTTP respons adfærd interne endpoints til at udløse automatisk rollback af svigtende implementeringer, og standardisere fejlhåndtering for at forhindre fejl i at blive maskeret, før du når kunden. # # Forpligtelse til løbende forbedring Hændelser som denne styrker vores forpligtelse til løbende at forbedre platformens pålidelighed. Vi behandler hver hændelse som en læringsmulighed, gennemgår vores processer, styrker detektions- og forebyggelsesmekanismer og investerer løbende i mere robust ingeniørpraksis. Vores mål er at holde hæve baren på tilgængelighed og gennemsigtighed for alle vores kunder. Unico Team.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 10. juli 2026 kl. 16.43 UTCinvestigating

   Vi oplever i øjeblikket ustabilitet i IDCLOUD-kapaciteter. Vores tekniske team undersøger allerede årsagen. Vi vil give opdateringer, så snart mere information bliver tilgængelig.

2. 10. juli 2026 kl. 17.12 UTCidentified

   Vi har identificeret en ustabilitet, der kan forårsage midlertidig nedetid eller latency i nogle af vores centrale verificering og risikoanalyse API 'er. Berørte tjenester: - Identitet & Validering: Identitet Verifikation, 1: 1 Validering, Serpro Simitality Retur - Risiko og svig: Risiko Score, svig risikoklassificering - Documentation & Liveness: Document Reuse & Capture, Liveness Nuværende status & næste trin: Vores Engineering team er allerede fuldt engageret og undersøge roden årsag. Vi arbejder aktivt på at isolere adfærd og genoprette normale operationer så hurtigt som muligt.

3. 10. juli 2026 kl. 17.25 UTCmonitoring

   Nuværende status & næste trin Det er lykkedes at gennemføre skadegørelsesaktioner, og systemet er nu stabilt. På dette tidspunkt, vores Engineering team fortsat aktivt overvåge platformens ydeevne for at sikre fortsat stabilitet og normale operationer. Tak for Deres tålmodighed og forståelse under denne hændelse. Dine tjenester bør nu fungere normalt.

4. 10. juli 2026 kl. 17.57 UTCresolved

   Sammenfatning og virkning Mellem 1: 21 og 2: 16 (Brasília Time) den 10. juli 2026, vi identificeret en udsving i tilgængeligheden af processen skabelse flow og relaterede rejser, hvilket resulterer i en midlertidig spike i fejlfrekvensen for nogle af vores vigtigste API 'er. - Påvirkningens omfang: Arrangementet påvirkede udelukkende tilgængeligheden af visse rejser i dette interval. Kunder, der ikke oplevede en stigning i deres fejlprocent i denne periode, blev ikke påvirket. - Dataintegritet: Der var intet kompromis med integriteten eller sikkerheden af de behandlede oplysninger. - Mitigation: En indledende workout blev anvendt inden for et par minutter, stopper mængden af fejl. Tjenesten blev fuldt normaliseret kl. 14.16, efter stabilitetsbekræftelse fra vores ingeniør- og overvågningshold. Rodsag Hændelsen blev udløst af ustabilitet i en infrastrukturtjeneste, efterfulgt af en pludselig forringelse i initialiseringen af relaterede interne komponenter. Forpligtelse og næste skridt Vi er dybt engageret i vores platforms modstandsdygtighed. De korrigerende og forebyggende foranstaltninger, der blev iværksat under hændelsen, overvåges allerede for at mindske risikoen for fremtidige hændelser af denne art. - Postmortem: En detaljeret teknisk rapport (Postmortem) vil snart blive delt med en komplet tidslinje, arkitektonisk analyse og en langsigtet handlingsplan med fastlagte frister. Vi beklager dybt den indvirkning og ustabilitet, der er forårsaget. Vores kunders tillid er vores højeste prioritet, og vi arbejder fortsat på at sikre vores tjenesters kvalitet. Med venlig hilsen, Unico Team

5. 14. juli 2026 kl. 14.08 UTCpostmortem

   * * Oversigt * * Den 10. juli 2026, mellem 1: 21 PM og 2: 09 PM\ (Brasília tid\), fejlfrekvensen i processen skabelse flow toppede på omkring 11% i omkring 9 minutter, med fortsat tilgængelighed nedbrydning indtil 2: 09 PM. Hændelsen var forårsaget af en ustabilitet i infrastrukturen konfiguration management komponent, som forhindrede biometrics service bælge i at initialisere korrekt. Virkningen blev forstærket af en præ- eksisterende hukommelse forbrug adfærd\ (som øgede frekvensen af pod genstarter\) og af en trafik spike, der udløste oprettelsen af nye tilfælde - som alle var ude af stand til at initialisere under konfigurationskomponentens ustabilitet vindue. Name * * Indvirkning * * Flere strømme blev påvirket samtidigt - herunder processkabelse, autentificering, biometri, betalinger og interne operationer - med fejl, der breder sig på tværs af alle tjenester, der er afhængige af den biometriske motor. På sit højeste nåede fejlfrekvensen op på 11%. Antallet af tilgængelige biometri service kapsler faldt til næsten nul i begge produktionsklynger i løbet af den mest kritiske vindue af hændelsen. Name * * Rodårsag * * Root årsag var relateret til en optimering mulighed i biometrics tjenesten start logik: programmet nægtede at komme op, hvis infrastrukturen konfiguration management komponent returneret en fejl under boot, selv når cachet data var tilgængelige for brug som en fallback. Denne logik behandlet en forbigående kommunikationsafbrydelse på samme måde som en permanent konfiguration fejl, hvilket gør fallback cache ubrugelig på præcis det øjeblik, det var nødvendigt mest. Da konfigurationskomponenten blev ustabil, blev hver kapsel, der forsøgte at genstarte - hvad enten det skyldtes hukommelsestryk eller automatisk skalering - fanget i en fejlløkke, som ikke kunne fuldføre initialiseringsprocessen. Name * * Opløsning * * Holdet indeholdt den oprindelige virkning ved at isolere trafik fra en af de berørte komponenter, som stoppede fejlen spike inden for omkring 9 minutter. Stabilisering af konfigurationskomponenten fulgt, så kapslerne kan komme op normalt. En nødløsning blev udarbejdet og indsat samme dag, fjerne den restriktive validering, der blokerede start - sikre fallback cache anvendes gennemsigtigt i lignende situationer går fremad. * * Lektioner lært * * Hændelsen afslørede, at tjenestens modstandsdygtighed mekanisme - fallback cache - eksisterede i arkitekturen, men blev neutraliseret af start logik, som prioriterede streng datavalidering i forhold til miljøet tilgængelighed. Opstartstier for kritiske tjenester skal udformes således, at de nedgraderes elegant, når der ydes støtte til infrastrukturkomponenter, der er ustabile og sikrer driftskontinuitet. * * Forpligtelse til stabilitet og løbende forbedring * * Vi vil fortsætte med at investere kraftigt i robustheden af vores infrastruktur for at sikre, at vores tjenester konsekvent opererer på de højeste niveauer af effektivitet, sikkerhed og pålidelighed. Unico Team.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. juli 2026 kl. 21.22 UTCidentified

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

2. 7. juli 2026 kl. 21.32 UTCmonitoring

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

3. 7. juli 2026 kl. 22.14 UTCresolved

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

4. 13. juli 2026 kl. 21.18 UTCpostmortem

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

1. 6. juli 2026 kl. 16.29 UTCidentified

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

2. 6. juli 2026 kl. 16.51 UTCmonitoring

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

3. 6. juli 2026 kl. 17.25 UTCresolved

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

4. 13. juli 2026 kl. 21.17 UTCpostmortem

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

1. 2. juli 2026 kl. 22.04 UTCidentified

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

2. 2. juli 2026 kl. 22.05 UTCidentified

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

3. 3. juli 2026 kl. 00.04 UTCmonitoring

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

4. 3. juli 2026 kl. 01.14 UTCresolved

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

5. 13. juli 2026 kl. 20.36 UTCpostmortem

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

1. 26. juni 2026 kl. 14.10 UTCresolved

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

2. 3. juli 2026 kl. 18.22 UTCpostmortem

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

1. 24. juni 2026 kl. 18.20 UTCidentified

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

2. 24. juni 2026 kl. 18.31 UTCmonitoring

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

3. 24. juni 2026 kl. 18.53 UTCresolved

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

4. 13. juli 2026 kl. 19.27 UTCpostmortem

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

1. 23. juni 2026 kl. 01.24 UTCinvestigating

   Prezado Cliente Nossa monitoração proativa detectou um comportamento uregelmæssig ingen ID Pay e no fluxo de onboarding do ByUnico. Embora a causa exata ainda esteja sob invgação, iso pode se manifestar como lentidão ou intermitência no serviço. En equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos comatualizações.

2. 23. juni 2026 kl. 01.39 UTCidentified

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

3. 23. juni 2026 kl. 01.53 UTCidentified

   Prezado Cliente Informamos que nossa equipe identificou a causa da instabilidade e está ativatente trabalhando na aplicação da solução. Seguimos empenhados em restabelecer o serviço o mais rapidamente oustível e mantemomos vocate informado sobre a evolução. Novas atualizações serão enviadas em breve.

4. 23. juni 2026 kl. 02.18 UTCmonitoring

   Prezado Cliente Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalches 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. juni 2026 kl. 02.41 UTCresolved

   Prezado Cliente Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalches 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. juli 2026 kl. 13.58 UTCpostmortem

   * * Oversigt * * Den 22. juni 2026, kl 9: 52\ (Brasília tid\), dokumentet besparelse flow blev ikke tilgængelig på grund af udmattelse af en sekventiel identifikator grænse i databasen. Fra det øjeblik, alle dokument indsættelse operationer begyndte at mislykkes, cascading fejl til flere afhængige tjenester. Hændelsen varede omkring 86 minutter. Name * * Indvirkning * * Flere kritiske tjenester blev påvirket samtidigt - herunder on-boardingstrømme, processkabelse, autentificering og betalinger. I nogle strømme faldt tilgængeligheden til under 3%. Klienter havde brugere påvirket af svigt eller forsinkelser ved forsøg operationer, der afhang af dokumentbesparelse. Name * * Rodårsag * * Den grundlæggende årsag var relateret til 32- bit id-typen, der anvendes i dokumenttabellen, som understøtter omkring 2,1 milliarder værdier; med den naturlige vækst i rekordvolumen over tid, blev denne grænse nået, så databasen ikke længere være i stand til at generere nye identifikatorer, så alle indsættelse operationer begyndte at mislykkes. Da der ikke var nogen overvågning konfigureret til at spore nærhed til denne grænse, udmattelse opstod brat og uden forudgående advarsel. Name * * Opløsning * * Holdet identificerede årsagen om cirka 20 minutter. Som en øjeblikkelig afbødning blev den sekventielle identifikator omkonfigureret til at bruge det negative område af samme datatype, frigør omkring 2,1 milliarder værdier uden at kræve nogen strukturelle ændringer i databasen. Løsningen blev valideret i lavere miljøer, før den blev anvendt på produktionen. Tjenesten begyndte at stabilisere kort efter fixet blev anvendt og blev overvåget indtil fuld bedring blev bekræftet. Name * * Lektioner lært * * Hændelsen fremhæver betydningen af at gennemføre overvågning for sekventiel identifikation brug i high-volume tabeller, med tidlige advarsler, der tillader udmattelse skal håndteres som planlagt vedligeholdelse; vedtage 8-byte id-typer fra starten for tabeller med høj skrivevolumen, herunder denne kontrol i skema gennemgang processer; og kortlægge og dokumentere de kritiske afhængigheder af centrale persistens tjenester, for at øge virkningen og prioritere kommunikation med berørte brugere hurtigere i fremtidige hændelser.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. juni 2026 kl. 13.08 UTCinvestigating

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

2. 19. juni 2026 kl. 18.34 UTCmonitoring

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

3. 19. juni 2026 kl. 19.42 UTCresolved

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

4. 3. juli 2026 kl. 20.36 UTCpostmortem

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

1. 12. juni 2026 kl. 15.29 UTCidentified

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

2. 12. juni 2026 kl. 17.03 UTCidentified

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

3. 12. juni 2026 kl. 18.17 UTCmonitoring

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

4. 12. juni 2026 kl. 18.31 UTCresolved

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

1. 12. juni 2026 kl. 14.58 UTCidentified

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

2. 12. juni 2026 kl. 17.31 UTCmonitoring

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

3. 12. juni 2026 kl. 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