Cronologia delle interruzioni di Unico

1. 30 agosto 2026 alle ore 02:35 UTCinvestigating

   Gentile cliente, Alle ore 11:00 (BRT) di venerdì 29 agosto 2026, abbiamo identificato un'instabilità che influisce sulla creazione di processi in IDCloud. Durante questo periodo, alcune richieste possono fallire o sperimentare più lentamente dei soliti tempi di risposta. Riconosciamo l'inconveniente che questo può causare e apprezzare la vostra comprensione. A breve verrà fornito un nuovo aggiornamento. Unico Team

2. 30 agosto 2026 alle ore 02:49 UTCidentified

   Il nostro team di ingegneria ha mappato l'origine dell'instabilità che colpisce la creazione di processo in IDCloud. Il team tecnico ha già iniziato ad applicare misure correttive, comprese le risorse di scaling nello strato interessato e il monitoraggio continuo degli indicatori chiave. Restaurare il servizio viene gestito con massima priorità e piena mobilitazione ingegneristica. Ribadiamo che saranno inviati a breve ulteriori aggiornamenti. Unico Team

3. 30 agosto 2026 alle ore 02:57 UTCmonitoring

   Gentile cliente, Il nostro team di ingegneri ha effettuato le azioni correttive necessarie per risolvere l'instabilità che influisce sulla creazione di processi in IDCloud. L'ambiente è tornato alla stabilità, con disponibilità e indicatori di tempo di risposta ripristinati ai normali livelli operativi a partire da 11:48 PM (BRT). Il servizio è disponibile per un uso normale. In questo momento, il nostro team tecnico rimane sotto il monitoraggio assistito, osservando attentamente l'ambiente per garantire prestazioni coerenti e agire immediatamente in caso di fluttuazione. Apprezziamo la vostra comprensione e ribadiamo che ulteriori aggiornamenti saranno inviati a breve. Unico Team

4. 30 agosto 2026 alle ore 03:15 UTCresolved

   Gentile cliente, Sommario esecutivo e impatto Tra le 11:00 e le 11:48 (BRT) il 29 agosto 2026, una creazione di processo in uscita in IDCloud. Durante questa finestra, alcuni clienti che utilizzano questi flussi hanno sperimentato guasti e aumentato i tempi di risposta, con la propagazione a viaggi dipendenti, tra cui l'autenticazione, la cattura dei documenti e la consegna delle notifiche. Non c'era alcun compromesso per l'integrità o la sicurezza delle informazioni trattate, e nessun dato è stato perso. Indicatori restituiti ai normali livelli operativi a 11:48 PM (BRT), con normalizzazione confermata sia nel nostro monitoraggio che sul lato cliente, coprendo la creazione e il completamento del processo. Causa radice e risoluzione L'origine è stata identificata nel nostro livello di dati: una routine di manutenzione interna è diventata bloccata, e le operazioni di applicazione hanno cominciato a queuing dietro di esso fino a quando il limite di connessione disponibile è stato esaurito, riducendo la capacità di elaborazione. Il nostro team di ingegneria ha interrotto chirurgicamente solo la routine bloccata, rilasciando immediatamente la coda. Le connessioni e la capacità di elaborazione sono state completamente ripristinate, senza modifiche dei dati. Impegno e passi successivi Il nostro team di ingegneria si concentrerà su tre fronti: limitando i tempi di attesa per le routine di manutenzione interna, impedendo routine concorrenti di correre contro la stessa struttura, e rafforzare la resilienza di servizio alle fluttuazioni nello strato di dati. Un postmortem dettagliato, tra cui la linea temporale completa e un piano d'azione con scadenze, sarà condiviso a breve. Ci scusiamo sinceramente per l'impatto sulle vostre operazioni e rimaniamo disponibili attraverso i nostri canali di supporto. Unico Team

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 10 agosto 2026 alle ore 20:26 UTCidentified

   Gentile cliente, Abbiamo rilevato un impatto su alcune richieste di IDCloud, che interessano la capacità di Behavior Alert (IDTrust) e il flusso 1:N. Questa instabilità può anche influenzare i clienti in Messico che utilizzano questa capacità. Il nostro team di ingegneria è mobilitato per risolvere il problema il prima possibile. Forniamo nuovi aggiornamenti a breve.

2. 10 agosto 2026 alle ore 20:29 UTCmonitoring

   Il nostro team di ingegneria ha identificato e implementato le azioni necessarie per risolvere l'instabilità nelle capacità di flusso IDCloud colpite. In questo momento, il team tecnico sta conducendo un'analisi dettagliata del nostro livello di dati e continua a monitorare l'ambiente. Ribadiamo che saranno inviati a breve ulteriori aggiornamenti.

3. 10 agosto 2026 alle ore 21:01 UTCresolved

   Sommario esecutivo e impatto Verso le 17:08, un avviso automatizzato ha rilevato una caduta di disponibilità nel servizio di riconoscimento facciale (1:N flusso), innescando l'incidente. Il problema è aumentato rapidamente e ha cominciato a influenzare il servizio di avviso di comportamento e, successivamente, il flusso di creazione di processo, a causa di scadere timeout tra questi servizi. L'impatto ha interessato un sottoinsieme di clienti che utilizzano queste funzionalità. La situazione è stata stabilita alle 17:22, con metriche di ritorno ai livelli normali. Causa radice e risoluzione La causa principale era un picco di traffico generato da un carico di lavoro interno, che ha inviato un alto volume di richieste di riconoscimento facciale direttamente nella pipeline biometrica, bypassando lo strato bordo utilizzato dal normale traffico client. Questo volume aggiuntivo satura la capacità del database che supporta il servizio di riconoscimento facciale. La saturazione ha causato timeout in quel servizio, che ha cascaded al servizio di orchestrazione del motore biometrico, poi al servizio di avviso del comportamento, e infine al flusso di creazione del processo utilizzando queste capacità. Per risolvere il problema, il team ha fermato il carico di lavoro responsabile del picco e aumentato la capacità del database interessato. Queste azioni hanno mitigato il problema, con il volume di errore di ritorno a livelli quasi zero. Impegno e passi successivi Un elemento di follow-up è stato aperto per implementare il limite di velocità per il tipo di carico di lavoro interno che ha causato il picco, come misura preventiva contro la ricorrenza. L'aumento di capacità per il database interessato è stato già effettuato durante l'incidente stesso.

4. 25 agosto 2026 alle ore 13:05 UTCpostmortem

   # Sommario # Il 10 agosto 2026, tra le 17:08 e le 17:27 \(Brasília time\), l'indicatore di disponibilità per il flusso di riconoscimento facciale 1:N è sceso sotto il 95%, con un impatto totale di circa 19 minuti. L'incidente è stato causato dalla saturazione del database di ricerca vettoriale utilizzato dal motore biometrico, risultante da un comportamento inaspettato nel meccanismo di consumo della coda, che ha generato un volume di chiamata 2.36 volte superiore a configurato. Il carico in eccesso ha raggiunto il limite massimo di scaling del database, causando tempi di fuga attraverso più servizi dipendenti e che interessano 55 utenti client con errori durante il periodo. # Impatto # Gli utenti del riconoscimento facciale, l'autenticazione e la creazione di processi fluiscono da più client esperti errori e timeout durante il periodo. La saturazione del database si è cascata attraverso i servizi di orchestrazione biometrica, motore e creazione di processi. La mitigazione è stata effettuata disabilitando un servizio interno e aumentando il limite massimo di scaling del database, stabilizzando il servizio alle 17:27. ♪Root Cause ♪ La causa principale era una combinazione di fattori legati al comportamento di servizio e alla capacità dell'infrastruttura coinvolta. Il servizio è stato configurato con un limite di 2 richieste al secondo, ma il meccanismo di consumo della coda si è comportato in modo inaspettato: i messaggi il cui trattamento ha superato la scadenza di riconoscimento sono stati ridisegnati dalla coda senza annullare l'esecuzione originale — trasformando 938 elementi di lavoro in 2.217 chiamate efficaci \(~8.4 RPS\). Questo traffico amplificato ha raggiunto il database senza passare attraverso lo strato di protezione dei bordi, che normalmente limiterebbe il volume di richiesta, dal momento che il percorso di rete utilizzato in questo flusso non ha attraversato quei controlli. Il database, già operativo vicino al suo limite massimo di scaling, non è stato in grado di assorbire il carico aggiuntivo — la sua CPU ha raggiunto l'88% mentre scaling fino al soffitto configurato di 100 nodi — e la latenza di query è saltata da ~3 secondi a ~18.75 secondi a p90, propagando timeout attraverso l'intera catena di servizi dipendenti. # Risoluzione # Il team ha identificato il processo in questione come la fonte del carico entro pochi minuti dall'avviso. Il processo è stato disattivato, e il limite massimo di scaling del database è stato aumentato da 100 a 150 nodi. Con queste due azioni, il servizio si è stabilizzato alle 17:27. # Lezioni imparate # L'incidente ha mostrato che il limite di velocità applicato solo sul lato di pubblicazione del messaggio è insufficiente quando il consumatore può amplificare il volume attraverso la ridisegna. I controlli di frequenza e di concordanza devono esistere anche sul lato del consumo. Inoltre, i servizi interni che accedono ai componenti critici attraverso percorsi che le protezioni dei bordi di bypass rappresentano un rischio strutturale — qualsiasi client interno può generare un carico incontrollato sulle infrastrutture condivise.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 31 luglio 2026 alle ore 12:42 UTCinvestigating

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

2. 31 luglio 2026 alle ore 13:08 UTCidentified

   Prezados clienti, Gostaríamos de atualizar o status sobre a visualização de documentos no painel de acompanhamento. O problema foi identificado com sucesso por nossa equipe técnica. Nessun momento, os engenheiros já estão subindo a correção para ribelecer a exibição correta de todos os envios na interface do remetente. Lembramos que o processamento, envio e assinatura dos documentis 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 luglio 2026 alle ore 13:20 UTCmonitoring

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

4. 31 luglio 2026 alle ore 14:06 UTCresolved

   Prezados clienti, 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 documentis foram totalmente ribelecidos, e a plataforma opera em completa estabilidade. Agradecemos pela compreensão e paciência de todos durante o processo. Atenciosamente,

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 luglio 2026 alle ore 14:04 UTCresolved

   Sintesi e impatto Vorremmo informarvi che l'incidente che colpisce temporaneamente il servizio di notifica ID Cloud Webhook è stato risolto. Periodo d'impatto: dalle 08:32 alle 10:05. Impatto della piattaforma: L'instabilità era strettamente limitata alla consegna della notifica di Webhook, con conseguente ritardo nella distribuzione dei messaggi. Non c'era degradazione della piattaforma principale, nessun guasto nel motore di liveness, e nessuna perdita di dati. Impatto del cliente: il problema ha interessato una piccola parte dei clienti. I clienti che hanno implementato un flusso di polling GET come contingenza (fallback) hanno sperimentato nessun downtime o impatto operativo. Causa radice e risoluzione Causa radice: L'instabilità è stata attivata da un aggiornamento della funzionalità nell'ambiente. Un errore temporaneo nelle autorizzazioni di accesso tra la coda di compito e la rotta di destinazione ha causato le richieste di essere negato, portando a un backlog temporaneo delle notifiche. Azione risolutiva: Il team tecnico ha completato il reindirizzamento del traffico al nuovo ambiente, ripristinando la corretta comunicazione tra i componenti e rilasciando il backlog di Webhooks. L'elaborazione è tornata alla normalità e la coda di spedizione è stata completamente cancellata. Impegno e passi successivi La stabilità dei nostri servizi è la nostra massima priorità. Per garantire la totale trasparenza e prevenire il ripetersi, il nostro team di ingegneri si concentrerà sui seguenti fronti: Postmortem dettagliato: Verrà preparato un rapporto completo con un'analisi approfondita delle cause e un piano d'azione preventivo. Miglioramenti di osservabilità: Regolaremo le metriche di monitoraggio per garantire una maggiore visibilità negli errori di comunicazione inter-service durante gli scenari di transizione. Ci scusiamo sinceramente per l'inconveniente e restiamo disponibili per ulteriori chiarimenti. Sinceramente, Unico Team

2. 7 agosto 2026 alle ore 13:08 UTCpostmortem

   # Sommario # Il 29 luglio 2026, tra le 8:32 e le 10:05 \(Brasília time\), il servizio di consegna webhook è stato degradato per circa 1 ora e 33 minuti. L'incidente è stato causato da una migrazione pianificata dell'infrastruttura che ha creato uno stato di incompatibilità transitoria: dopo che le rotte interne sono state commutate al nuovo cluster, il servizio webhook ha iniziato a generare token di autenticazione dal nuovo cluster, ma le consegne sono state ancora dirette al vecchio cluster - che ha respinto i token con un errore di autorizzazione. Gli eventi persi sono stati ritrattati su richiesta. # Impatto # Più prodotti sono stati colpiti simultaneamente — tra cui autenticazione, pagamenti e flussi di bordo. Gli utenti di clienti che si affidavano esclusivamente alle notifiche webhook per continuare i loro flussi commerciali hanno subito interruzioni operative durante il periodo. I clienti che avevano implementato il polling attivo come meccanismo di fallback hanno avuto un impatto ridotto. ♪Root Cause ♪ La causa principale è stata identificata nella pianificazione delle migrazioni: la procedura non ha mappato la dipendenza incatenata del flusso webhook — dove il percorso interno crea un compito asincrono che, a sua volta, chiama il percorso pubblico per la consegna. Migrando le rotte interne e le vie pubbliche in passaggi separati, è stata creata una finestra di incompatibilità in cui i gettoni generati dal nuovo cluster sono stati respinti dalla vecchia politica di autorizzazione del cluster, che ha specificamente convalidato l'identificatore del conto di servizio precedente. Questo scenario non è stato identificato durante la valutazione del rischio del cambiamento, e nessuno degli indicatori di qualità dei servizi esistenti ha coperto lo strato di consegna asincrono dove il fallimento si è materializzato. # Risoluzione # Il team ha identificato l'incompatibilità dei token come fonte dei guasti e completato la migrazione delle rotte pubbliche al nuovo cluster, eliminando la divergenza. Da quel momento in poi, le consegne in sospeso nella coda iniziarono ad elaborare normalmente. L'impatto è cessato alle 10:05 e il traffico sul vecchio cluster ha raggiunto zero alle 10:32 AM. # Lezioni imparate # L'incidente ha dimostrato che le migrazioni che coinvolgono flussi di consegna asincrono a catena richiedono che tutte le rotte che partecipano alla catena — interna e pubblica — vengano migrate in modo coordinato, senza finestre di incompatibilità tra cluster. L'approccio graduale utilizzato, mentre adatto per la maggior parte delle migrazioni, ha creato un periodo di guasto prolungato qui che potrebbe essere stato evitato con una transizione atomica o una finestra di transizione molto più breve. Inoltre, la mancanza di osservabilità allo strato di consegna asincrono era il motivo per cui l'incidente non è stato rilevato internamente — gli indicatori esistenti misuravano solo l'accettazione degli eventi, non la consegna effettiva. Creazione di avvisi dedicati per guasti e backlog a questo livello è il miglioramento di monitoraggio più urgente identificato.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 luglio 2026 alle ore 21:47 UTCinvestigating

   Gentile cliente, Stiamo attualmente indagando su un'instabilità nei nostri Webhooks che sta influenzando la latenza nella consegna dei dati. Il nostro team di ingegneri sta lavorando attivamente per risolvere il problema il più rapidamente possibile. Vi forniremo ulteriori aggiornamenti a breve.

2. 24 luglio 2026 alle ore 21:53 UTCmonitoring

   Gentile cliente, Il nostro team di ingegneria ha identificato e implementato le azioni necessarie per risolvere l'instabilità Webhook che influisce sulla latenza di consegna dei dati. In questo momento, il team tecnico sta conducendo un'analisi dettagliata del nostro livello di dati e continua a monitorare l'ambiente. Ribadiamo che saranno inviati a breve ulteriori aggiornamenti.

3. 24 luglio 2026 alle ore 22:18 UTCresolved

   Sommario esecutivo e impatto A partire dalle ore 18:05 (ora Bresília), un'instabilità si è verificata nel servizio Webhook, portando al fallimento nel trattamento degli eventi e la consegna delle notifiche per le operazioni colpite durante questo periodo. Causa radice e risoluzione L'incidente è stato causato da un problema con un account di servizio condiviso utilizzato in più servizi, con conseguente guasti di autenticazione. Dopo aver identificato la causa principale, il team di ingegneria ha ripristinato le credenziali e la configurazione richieste. L'operazione normale è stata completamente ristabilita alle 18:29 PM (BRT). Impegno e passi successivi Nell'ambito del miglioramento continuo e della mitigazione dei rischi, il team di ingegneria esaminerà le dipendenze delle risorse e la gestione degli accessi attraverso i servizi. Ciò impedirà simili problemi di configurazione nelle future regolazioni delle infrastrutture.

4. 3 agosto 2026 alle ore 20:00 UTCpostmortem

   # Sommario # Il 24 luglio 2026, tra le 18:05 e le 18:29 \(Brasília time\), il servizio di creazione e consegna webhook non era disponibile per circa 24 minuti. L'incidente è stato causato dalla perdita di accesso a un account di servizio infrastrutturale durante un processo di decommissione delle risorse collegato a una migrazione di cluster effettuata giorni prima. L'account interessato è stato condiviso da più servizi senza che questa dipendenza sia documentata, causando il servizio webhook per perdere la sua capacità di autenticazione e smettere di creare e fornire eventi. # Impatto # La creazione e la consegna di eventi Webhook è stata interrotta durante il periodo, che colpisce 18 utenti client con più di 1.550 errori registrati. L'impatto è cascapato ad altri servizi che dipendono dallo stesso flusso di autenticazione, causando il degrado simultaneo attraverso diverse funzionalità della piattaforma. ♪Root Cause ♪ La causa principale è stata identificata nella configurazione della dipendenza dal servizio. Questa dipendenza cross-service non è stata né documentata né visibile in qualsiasi mappatura di dipendenza. Quando il processo di decommissione ha rimosso l'account come parte della pulizia delle risorse del servizio originale, non c'era alcuna validazione automatizzata per verificare se l'account fosse ancora utilizzato da altri servizi attivi. L'assenza di questa salvaguardia ha mantenuto la dipendenza nascosta fino alla sua rimozione ha causato errori di autenticazione diffusi. # Risoluzione # Il team ha rapidamente identificato l'account di servizio instabile come fonte dei guasti di autenticazione. L'account è stato regolato manualmente e applicato al cluster, ripristinando il servizio alle ore 18:29. La durata totale dell'impatto è stata di circa 24 minuti. # Lezioni imparate # L'incidente ha esposto i rischi di configurazioni legacy che creano dipendenze nascoste tra i servizi: un unico cambiamento di risorse durante la manutenzione pianificata è stato sufficiente per interrompere simultaneamente più servizi. Il processo di decommissione delle risorse infrastrutturali deve includere la convalida automatica della dipendenza prima di ogni cambiamento.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 luglio 2026 alle ore 16:39 UTCidentified

   Gentile cliente, Stiamo indagando su un'instabilità nelle funzionalità IDCloud che influisce sui flussi di autenticazione nel percorso di processo, in particolare impatto sul Web Journey (ex ByUnico). Il nostro team di ingegneria è mobilitato per risolvere il problema il prima possibile. Vi forniremo ulteriori aggiornamenti a breve.

2. 21 luglio 2026 alle ore 16:49 UTCmonitoring

   Gentile cliente, Il nostro team di ingegneria ha identificato e implementato le azioni necessarie per risolvere l'instabilità nelle capacità di flusso IDCloud colpite. In questo momento, il team tecnico sta conducendo un'analisi dettagliata del nostro livello di dati e continua a monitorare l'ambiente. Ribadiamo che saranno inviati a breve ulteriori aggiornamenti.

3. 21 luglio 2026 alle ore 18:02 UTCresolved

   Sommario esecutivo e impatto A partire dalle ore 12:44 (ora di Bresília) il 21 luglio 2026, una parte degli utenti nel ridotto viaggio di onboarding ha sperimentato un carico più lento degli schermi iniziali nel flusso. L'impatto è stato osservato in tutti gli ambienti in cui questo viaggio viene utilizzato, influenzando la velocità percepita e, in misura minore, la capacità degli utenti di completare il processo durante questo periodo. Causa radice e risoluzione L'indagine è in corso per confermare la causa principale definitiva dell'incidente. Non c'è stato alcun impatto su server, rete o infrastrutture — il problema è stato confermato per essere isolato all'esperienza sullo schermo sul dispositivo dell'utente. Come misura di contenimento, il team responsabile ha applicato un aggiustamento preventivo a 1:39 PM (BRT), e i tempi di caricamento tornati alla normalità in pochi minuti. L'analisi per convalidare e confermare la causa principale è ancora in corso dal team tecnico. Impegno e passi successivi Nell'ambito del continuo miglioramento dei processi di risposta agli incidenti, il team si impegna a migliorare il flusso di escalation automatico dei team responsabili, rendendo l'attivazione ancora più diretta ed efficace dal momento in cui si apre un incidente. Inoltre, il monitoraggio della velocità di carico sarà rafforzato durante la presentazione di nuovi cambiamenti a questo viaggio, con l'obiettivo di identificare e correggere le potenziali regressioni ancora più velocemente, minimizzando l'impatto agli utenti in situazioni simili in corso.

4. 3 agosto 2026 alle ore 14:01 UTCpostmortem

   # Sommario # Il 21 luglio 2026, tra le 12:44 e 1:43 PM \(Brasília time\), indicatori di performance di carico della pagina per il viaggio ridotto degradato gravemente, con tempo medio di carico che passa da ~4.8s a ~8,9s e il p95 raggiungendo 31,5 secondi. L'incidente è stato causato dal limite di tasso applicato dall'infrastruttura cloud sulle connessioni provenienti dal fornitore, che ha impedito alle attività di frontend di caricare. # Impatto # Gli utenti di 32 clienti hanno sperimentato carichi di pagina estremamente lenti o guasti di carico completi, con circa 94 errori di viaggio registrati. Gli errori di "Initialization Timeout" — innescati quando l'applicazione non riesce a montare entro 30 secondi — hanno raggiunto circa 23 mila eventi durante il periodo. ♪Root Cause ♪ La causa principale è stata identificata nello strato di rete dell'infrastruttura: il provider CDN consolida il traffico attraverso un limitato insieme di indirizzi IP in uscita. Un picco di nuove connessioni TCP e handshake TLS provenienti da questi IP ha innescato i meccanismi di difesa automatica di rete-strato dell'infrastruttura cloud, che ha iniziato connessioni di limitazione di velocità anche prima dell'elaborazione HTTP. Poiché questi guasti si sono verificati nello strato di rete — prima dell'elaborazione HTTP — non sono comparsi nei registri delle richieste standard, rendendo il problema invisibile al monitoraggio convenzionale e complicando significativamente la diagnosi. # Risoluzione # L'impatto è cessato con il recupero naturale del limite di velocità applicato dall'infrastruttura cloud. La disattivazione di un componente, inizialmente contrassegnato come una possibile causa, coincise temporalmente con il recupero, ma fu successivamente confermato di non essere correlato all'incidente. Le correzioni di configurazione — consentendo HTTP Keep-Alive con un timeout esteso e aggiungendo una regola di permesso per gli IP CDN allo strato di protezione dei bordi — sono state identificate come elementi di follow-up dai team di supporto dei provider coinvolti. # Lezioni imparate # L'incidente ha evidenziato che i guasti nello strato di rete tra l'infrastruttura CDN e cloud sono invisibili al monitoraggio standard delle applicazioni, creando un punto cieco significativo. Come elementi di follow-up, il team ha identificato la necessità di implementare le correzioni di configurazione consigliate dai fornitori e di espandere l'osservabilità nello strato di asset delivery per rilevare proattivamente questo tipo di degrado.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 luglio 2026 alle ore 14:39 UTCidentified

   Gentile cliente, Stiamo indagando su un'instabilità nelle nostre capacità di IDCloud, che influisce sui flussi di dati di processo e di processo. Il nostro team di ingegneria è mobilitato per risolvere il problema il prima possibile. Vi forniremo ulteriori aggiornamenti a breve.

2. 21 luglio 2026 alle ore 14:46 UTCidentified

   Stiamo continuando a lavorare per risolvere questo problema.

3. 21 luglio 2026 alle ore 14:50 UTCmonitoring

   Gentile cliente, Il nostro team di ingegneria ha identificato e implementato le azioni necessarie per risolvere l'instabilità nelle capacità di flusso IDCloud colpite. In questo momento, il team tecnico sta conducendo un'analisi dettagliata del nostro livello di dati e continua a monitorare l'ambiente. Ribadiamo che saranno inviati a breve ulteriori aggiornamenti.

4. 21 luglio 2026 alle ore 16:00 UTCresolved

   Sommario esecutivo e impatto Il 21 luglio 2026, intorno alle 11:17 AM BRT, una diminuzione della disponibilità è stata rilevata nei flussi di processo e di processo IDCloud. Durante la finestra di impatto, una parte dei clienti ha sperimentato elevata latenza e fallimenti (timeouts) in queste operazioni, che si è propagato attraverso la catena di servizi dipendenti. L'impatto effettivo è stato concentrato in una finestra di circa 23 minuti. Al picco, gli indicatori di errore e la latenza erano al di sopra dei livelli operativi normali. Causa radice e risoluzione L'indagine ha indicato il degrado di un database letto (replica) che supporta queste capacità come origine. Questo database ha cominciato a mostrare un aumento del tempo di esecuzione di carico e query, con la contention interna che ha bloccato l'elaborazione e sostenuto le richieste di lettura. Di conseguenza, i servizi sopra di esso hanno iniziato accumulando timeout e innescando meccanismi di protezione (rompatori di circuito), producendo l'effetto di cascata sperimentato dai clienti. Impegno e passi successivi Unico si occupa di questo incidente con un postmortem dettagliato, già in fase di elaborazione, e terrà una riunione di revisione post-incidente (PiR) per consolidare le azioni preventive. Tra i follow-up già sollevati durante la risposta ci sono la preparazione di routine e query diagnostici per accelerare l'identificazione della contention in questo strato di database, e una migliore osservabilità sui database coinvolti. Le azioni preventive dettagliate saranno condivise nel postmortem. Riaffermiamo il nostro impegno per la stabilità e l'affidabilità della piattaforma e ci scusiamo per l'inconveniente causato durante il periodo di instabilità. Squadra Unico.

5. 28 luglio 2026 alle ore 12:10 UTCpostmortem

   # Sommario # Il 21 luglio 2026, tra le 11:41 e le 11:43 AM \(Brasília time\), il flusso di creazione del processo è diventato non disponibile, con il tasso di errore di servizio principale che raggiunge il 42% e la latenza p99 a 15.75 secondi. L'incidente è stato causato dalla saturazione sul database di biometria di lettura replica: il pool di memoria del database non è stato più in grado di servire il dataset più frequentemente accessibile, causando query normalmente veloci di cadere indietro alle letture del disco, creando una spirale di auto-rinforzo di sessioni accumulate e aumentando la la latenza. # Impatto # Gli utenti della creazione del processo, l'autenticazione e i flussi di pagamenti attraverso più client hanno ricevuto errori e timeout durante il periodo. Il database principale rimase intatto durante l'incidente — il fallimento è stato isolato alla replica di lettura. ♪Root Cause ♪ La causa principale era la saturazione: le query utilizzate nel flusso di autenticazione stavano eseguendo ampie scansioni sulle tabelle critiche a causa degli indici mancanti. In condizioni normali, questo comportamento è stato tollerato dall'infrastruttura del database. Quando la capacità di memoria ha raggiunto il suo limite e non poteva più mantenere i dati più accessibili nella cache, ogni lettura ha cominciato a recuperare i dati dal disco, rendendo il costo di ogni query esponenzialmente più alto. Questo brusco effetto di collasso — dove il graduale degrado dà il via ad un fallimento diffuso — è diventato auto-riinforzo come sessioni accumulate in attesa di risposte e la contention delle risorse del database interno è aumentata. Inoltre, tutto il traffico letto per il flusso critico è stato concentrato su una singola replica, senza distribuzione o percorso alternativo, eliminando qualsiasi resilienza a questo tipo di degrado. # Risoluzione # Il database si è ritrovato naturalmente come le sessioni accumulate sono state drenate, non richiedendo interventi manuali. Il team è salito al team del database e ha monitorato la stabilizzazione dei servizi. L'incidente è stato chiuso dopo la conferma che l'operazione normale è stata ripristinata. # Lezioni imparate # L'incidente ha rivelato lacune strutturali nello strato del database: indici mancanti su query critiche e concentrazione di tutto il traffico letto su una singola replica senza percorso alternativo. Come follow-up, il team ha priorizzato la creazione degli indici mancanti, la distribuzione del traffico di lettura attraverso le repliche, e la costruzione di runbook diagnostici per accelerare la risposta in futuri incidenti di natura simile.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 20 luglio 2026 alle ore 12:33 UTCidentified

   Gentile cliente, Abbiamo identificato un'instabilità in alcune delle nostre capacità IDCloud, che interessano GetSelfie, la creazione di processi e i flussi di dettagli di processo per il Web Journey (ex ByUnico). I flussi API Journey (ByClient) non sono stati influenzati. Il nostro team di ingegneria è mobilitato per risolvere il problema il prima possibile. Seguiremo a breve con ulteriori aggiornamenti.

2. 20 luglio 2026 alle ore 12:35 UTCidentified

   Stiamo continuando a lavorare per risolvere questo problema.

3. 20 luglio 2026 alle ore 12:39 UTCmonitoring

   Gentile cliente, Il nostro team di ingegneria ha identificato e implementato le azioni necessarie per risolvere l'instabilità nelle capacità di flusso IDCloud colpite. In questo momento, il team tecnico sta conducendo un'analisi dettagliata del nostro livello di dati e continua a monitorare l'ambiente. Ribadiamo che saranno inviati a breve ulteriori aggiornamenti.

4. 20 luglio 2026 alle ore 13:22 UTCresolved

   Sommario esecutivo e impatto Abbiamo identificato un'instabilità che influenza i flussi di cattura e visualizzazione del processo, nonché l'autenticazione, per il Viaggio Web, con impatto tra 09:07 e 09:21 (BRT). L'impatto ha raggiunto una parte dei clienti utilizzando questo flusso; l'API Journey non è stato interessato. Causa radice e risoluzione La causa principale è legata a una modifica di configurazione applicata nella produzione, che ha causato un aumento del carico su un componente del database interno. Questo aumento di carico ha sollevato latenza e gli errori in uno strato di integrazione, che a sua volta ha innescato un meccanismo protettivo e temporaneamente interrotto i flussi di Web Journey. Il team di ingegneria ha ripiegato il cambiamento di configurazione per mitigare il problema, e la situazione normalizzata poco dopo. Impegno e passi successivi Il team di ingegneri continua a monitorare l'ambiente seguendo il rollback delle modifiche apportate. Un postmortem dettagliato sarà condiviso dal nostro team nei prossimi giorni. Ci scusiamo per l'inconveniente. Squadra Unico!

5. 4 agosto 2026 alle ore 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.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 luglio 2026 alle ore 14:02 UTCinvestigating

   Gentile cliente, Stiamo indagando su un'instabilità nel nostro sistema di autenticazione per i portali Unico People e stiamo anche valutando i problemi nel nostro servizio di messaggistica che interessa i clienti IDCloud. Il nostro team di ingegneria è mobilitato per risolvere il problema il prima possibile. Forniremo aggiornamenti a breve.

2. 16 luglio 2026 alle ore 14:08 UTCmonitoring

   Gentile cliente, Il nostro team ha identificato il problema e ha preso provvedimenti per risolvere l'incidente. Abbiamo sperimentato un'instabilità nel nostro sistema di autenticazione per i portali Unico People, così come i problemi nel nostro servizio di messaggistica che interessa i clienti nel flusso IDCloud, per la consegna di SMS e email. Il nostro team di ingegneria rimane mobilitato, monitorando l'ambiente per garantire che continui a funzionare correttamente.

3. 16 luglio 2026 alle ore 15:28 UTCresolved

   Sommario esecutivo e impatto Alle ore 10:51 del 07/16/2026, un problema è stato identificato nel servizio di autenticazione sul portale di ammissione Unico People e in messaggistica, che ha interessato la consegna di SMS e link e-mail ai client Unico People e IDCloud, nonché l'autenticazione client B2C sul portale di ammissione Unico People. L'impatto è stato limitato a questi due flussi e non ha influenzato il percorso critico del prodotto. L'incidente durò circa 30 minuti fino a piena risoluzione. Causa radice e risoluzione La causa principale è stata identificata come pressione di archiviazione su un nodo del cluster di messaggistica, che ha raggiunto una soglia critica del disco, degradando l'elaborazione delle code responsabili per la consegna dei messaggi e l'autenticazione. Il team di ingegneria ha aumentato la capacità di archiviazione del cluster a circa 10:59 AM, che ha permesso code e indicatori di monitoraggio per normalizzare in pochi minuti. L'ambiente è stato monitorato finché non è stato confermato il pieno recupero, e l'incidente è stato chiuso alle 11:20 AM. Impegno e passi successivi Il team di ingegneri esaminerà i criteri di escalation e priorità di questo tipo di degrado, dal momento che gli avvisi correttamente identificati il problema, ma il flusso di escalation automatico al team responsabile può essere migliorato. Un postmortem dettagliato viene preparato e sarà condiviso nei prossimi giorni.

4. 3 agosto 2026 alle ore 12:14 UTCpostmortem

   # Sommario # Il 16 luglio 2026, tra le 10:12 e le 11:10 AM \(Brasília time\), il servizio di messaggistica e autenticazione è stato degradato per circa 58 minuti. La causa era la saturazione del disco su uno dei nodi nel cluster della coda del messaggio, che, al raggiungimento del limite configurato, bloccava automaticamente tutti gli editori, causando un backlog di fino a 33 mila messaggi nella coda. L'impatto ha interessato la consegna dei link di autenticazione via SMS e-mail, nonché il flusso di autenticazione dell'utente finale sul portale di ammissione Unico People. # Impatto # Gli utenti in attesa di link di autenticazione via SMS o e-mail non li hanno ricevuti durante il periodo. Gli utenti finali di un prodotto di gestione della gente che tenta di autenticarsi sul portale di ammissione non sono stati anche in grado di accedere al servizio. L'impatto è stato contenuto dopo che il disco del cluster è stato ampliato. ♪Root Cause ♪ La causa principale è stata identificata nel flusso di elaborazione dei messaggi: carichi di pagamento eccessivamente grandi — generati da un componente di auditing che includeva dati inutili — ha superato il limite di dimensione accettato dal cluster della coda dei messaggi. Dal momento che sono stati respinti deterministicamente su ogni tentativo, questi messaggi sono stati indirizzati a file di letter morti dopo aver esaurito tutte le storie. Queste code non avevano alcuna politica di scadenza o di pulizia automatica, causando messaggi di accumulare indefinitamente e progressivamente consumare lo spazio del disco del cluster. # Risoluzione # Il disco del cluster è stato ampliato a 500 GB per nodo, che ha normalizzato immediatamente le code e le metriche del cluster. Il servizio è tornato alla normalità alle 11:10. La causa della radice strutturale — l'accumulo indefinito nelle code delle lettere morte — rimane come elemento di follow-up da affrontare. # Lezioni imparate # L'incidente rafforza che l'affrontare solo il sintomo \(saturazione del rischio\) senza indagare la causa principale dell'accumulo garantisce la ricorrenza del problema. L'assenza di una politica del ciclo di vita \(TTL/expiration\) per le code delle lettere morte e la mancanza di convalida delle dimensioni del payload prima della pubblicazione sono le due lacune strutturali centrali da correggere. Inoltre, l'avviso che ha segnalato il problema è stato classificato come bassa priorità, che ha causato un ritardo di circa 38 minuti tra l'avviso che è stato innescato e l'apertura formale dell'incidente — un intervallo inaccettabile per un degrado di servizio critico.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 luglio 2026 alle ore 12:51 UTCidentified

   Gentile cliente, Abbiamo identificato un'instabilità nella capacità di verifica dell'identità, generando un errore in una piccola parte delle richieste di IDCloud. Il nostro team di ingegneria è già mobilitato per la diagnosi e lavorare per identificare la causa principale al fine di normalizzare il servizio il prima possibile. In questo momento, il team tecnico sta conducendo analisi dettagliate nel nostro livello di dati per mitigare l'impatto. Noi rafforziamo che ulteriori aggiornamenti saranno inviati a breve.

2. 13 luglio 2026 alle ore 13:06 UTCmonitoring

   Gentile cliente, Il nostro team di ingegneria ha identificato e implementato le azioni per risolvere l'instabilità nella capacità di verifica dell'identità che stava generando un errore in una piccola parte delle richieste di IDCloud. In questo momento, il team tecnico sta conducendo analisi dettagliate nel nostro livello di dati e continua a monitorare l'ambiente. Noi rafforziamo che ulteriori aggiornamenti saranno inviati a breve.

3. 13 luglio 2026 alle ore 13:47 UTCresolved

   Sommario esecutivo e impatto Il 13 luglio 2026, abbiamo identificato un'instabilità nella nostra capacità di verifica dell'identità, generando errori su una porzione minima di richieste di IDCloud, che interessano più flussi di autenticazione. Il problema è stato rilevato attraverso avvisi di disponibilità automatizzati intorno alle 9:27 AM BRT, con un leggero aumento di errori già evidenti da circa 8:00 AM BRT e un significativo peggioramento a partire dalle 9:07 AM BRT, raggiungendo l'impatto di picco intorno alle 9:49 AM BRT. Causa radice e risoluzione La causa principale è stata identificata come un cambiamento graduale applicato a un componente di autenticazione interna, che ha causato un fallimento nella convalida della firma di token di sessione. Una volta confermata la causa principale, il team di ingegneria ha annullato il cambiamento, e la disponibilità di servizio è tornato alla normalità. La fase più critica dell'impatto è durata circa 44 minuti. Impegno e passi successivi L'ingegneria sta valutando i miglioramenti al processo di cambiamento-validazione per rotazioni graduali che interessano i componenti di autenticazione critici, compresi i meccanismi di rollback automatico in caso di punte di errore durante questo tipo di rollout. Un postmortem dettagliato dovrebbe essere condiviso internamente come passo successivo.

4. 20 luglio 2026 alle ore 22:47 UTCpostmortem

   # Postmortem: Instabilità del flusso di autenticazione ** Data incidente: ** 13 luglio 2026 ** Durata dell'impatto: ** ~44 minuti # Il 13 luglio 2026, abbiamo identificato un degrado della disponibilità nei flussi di autenticazione della piattaforma. L'incidente è stato causato da un'incompatibilità introdotta durante un'implementazione laminata di un componente interno responsabile della convalida dei token di sicurezza. La causa è stata diagnosticata dai nostri team di operazioni, e rotolare indietro la stabilità del sistema di aggiornamento ripristinato in pochi minuti. ## Impact Il degrado è durato circa 44 minuti e ha colpito simultaneamente più flussi di autenticazione sulla piattaforma, con conseguente un tasso di errore di circa lo 0,9% nei servizi di customer-facing. Durante questo periodo, alcuni utenti finali hanno sperimentato l'instabilità e hanno visto messaggi generici di errore \(HTTP 500\) quando si tenta di autenticare. Anche se l'evento durò 44 minuti, oscillava tra la latenza aumentata e l'invalidità. # Causa radice # Il fallimento è stato causato da un difetto software introdotto in un aggiornamento al componente di convalida del token di sicurezza, con conseguente incompatibilità tra le istanze che eseguono diverse versioni. Questa incompatibilità non è stata rilevata negli ambienti di prova, poiché ha richiesto l'esecuzione simultanea e parallela di diverse versioni. Inoltre, il endpoint interno ha restituito una risposta di successo HTTP anche quando la validazione non è riuscita, che ha impedito ai sistemi di monitoraggio automatizzati della distribuzione di rilevare il problema e di arrestare automaticamente il rollout. ## Risoluzione Una volta identificata la causa, il team di chiamata ha eseguito un rollback del componente interessato, ripristinando immediatamente la disponibilità dei flussi di autenticazione. L'incidente è stato rilevato da avvisi SLO automatizzati entro pochi minuti dall'inizio del degrado, e l'escalation ha permesso la diagnosi completa e la mitigazione dell'incidente. # Lezioni imparate Noi miglioreremo la validazione della versione-compatibilità nelle implementazioni di rotolamento, regolare il comportamento di risposta HTTP dei endpoint interni per attivare il rollback automatico delle implementazioni di fallimento e standardizzare la gestione degli errori per evitare che i guasti vengano mascherati prima di raggiungere il cliente. ## Impegno al miglioramento continuo Gli incidenti come questo rafforzano il nostro impegno a migliorare continuamente l'affidabilità della piattaforma. Trattiamo ogni incidente come opportunità di apprendimento, riesaminando i nostri processi, rafforzando i meccanismi di rilevamento e prevenzione, e investendo continuamente in pratiche ingegneristiche più robuste. Il nostro obiettivo è quello di continuare a crescere la barra sulla disponibilità e la trasparenza per tutti i nostri clienti. Squadra Unico.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 10 luglio 2026 alle ore 16:43 UTCinvestigating

   Attualmente stiamo sperimentando l'instabilità nelle capacità di IDCLOUD. Il nostro team tecnico sta già indagando sulla causa principale. Forniremo aggiornamenti non appena ulteriori informazioni saranno disponibili.

2. 10 luglio 2026 alle ore 17:12 UTCidentified

   Abbiamo identificato un'instabilità che potrebbe causare tempi di fermo temporaneo o latenza in alcune delle nostre API di verifica e analisi dei rischi fondamentali. Servizi interessati: - Identity & Validation: Identity Verification, 1:1 Validation, Serpro Simility Return - Rischio e frode: punteggio di rischio, classificazione del rischio di frode - Documentazione & Liveness: Riutilizzo e Cattura dei documenti, Vita Stato attuale & passi successivi: Il nostro team di ingegneria è già completamente impegnato e indagare la causa principale. Stiamo lavorando attivamente per isolare il comportamento e ripristinare le operazioni normali il più rapidamente possibile.

3. 10 luglio 2026 alle ore 17:25 UTCmonitoring

   Stato attuale e passi successivi Le azioni di mitigazione sono state applicate con successo, e il sistema è ora stabile. In questo momento, il nostro team di Ingegneria continua a monitorare attivamente le prestazioni della piattaforma per garantire la stabilità e le operazioni normali. Grazie per la vostra pazienza e comprensione durante questo incidente. I tuoi servizi dovrebbero ora funzionare normalmente.

4. 10 luglio 2026 alle ore 17:57 UTCresolved

   Sommario esecutivo e impatto Tra 1:21 e 14:16 PM (Brasília Time) il 10 luglio 2026, abbiamo identificato una fluttuazione nella disponibilità del flusso di creazione del processo e dei relativi viaggi, con conseguente un picco temporaneo nella velocità di errore di alcune delle nostre API principali. - Campo d'impatto: L'evento ha interessato esclusivamente la disponibilità di alcuni viaggi durante questo intervallo. I clienti che non hanno sperimentato un aumento del tasso di errore durante questo periodo non sono stati influenzati. - Integrità dei dati: non c'era alcun compromesso per l'integrità o la sicurezza delle informazioni trattate. - Mitigazione: Una prima soluzione è stata applicata in pochi minuti, arrestando il volume degli errori. Il servizio è stato completamente normalizzato alle 14:16 PM, dopo la conferma della stabilità dai nostri team di Ingegneria e Monitoraggio. Causa di radice L'incidente è stato innescato dall'instabilità in un servizio infrastrutturale, seguito da un repentino degrado nell'inizializzazione di componenti interni correlati. Impegno e passi successivi Siamo profondamente impegnati nella resilienza della nostra piattaforma. Le azioni correttive e preventive avviate durante l'incidente sono già state monitorate per mitigare il rischio di futuri avvenimenti di questa natura. - Postmortem: Presto sarà condivisa una relazione tecnica dettagliata (Postmortem), contenente la linea temporale completa, l'analisi architettonica e un piano d'azione a lungo termine con scadenze definite. Ci scusiamo sinceramente per l'impatto e l'instabilità causate. La fiducia dei nostri clienti è la nostra massima priorità, e continuiamo a lavorare continuamente per garantire l'eccellenza dei nostri servizi. Sinceramente, Unico Team

5. 14 luglio 2026 alle ore 14:08 UTCpostmortem

   # Sommario # Il 10 luglio 2026, tra le 1:21 e le 2:09 \(Brasília time\), il tasso di errore nella creazione del processo è salito a circa 11% per circa 9 minuti, con il degrado di disponibilità continuato fino alle 2:09 PM. L'incidente è stato causato da un'instabilità nella componente di gestione della configurazione delle infrastrutture, che ha impedito ai pod di servizio biometrici di inizializzare correttamente. L'impatto è stato amplificato da un comportamento preesistente di consumo di memoria \(che ha aumentato la frequenza di pod riarts\) e da un picco di traffico che ha innescato la creazione di nuove istanze — tutte in grado di inizializzare durante la finestra di instabilità del componente di configurazione. # Impatto # I flussi multipli sono stati colpiti simultaneamente — tra cui la creazione di processo, l'autenticazione, la biometria, i pagamenti e le operazioni interne — con errori di propagazione in tutti i servizi dipendenti dal motore biometrico. Al suo picco, il tasso di errore raggiunse l'11%. Il numero di baccelli di servizio biometrici disponibili è sceso a quasi zero in entrambi i cluster di produzione durante la finestra più critica dell'incidente. ♪Root Cause ♪ La causa principale era legata ad un'opportunità di ottimizzazione nella logica di avvio del servizio biometrico: l'applicazione ha rifiutato di venire se il componente di gestione della configurazione dell'infrastruttura ha restituito un guasto durante l'avvio, anche quando i dati della cache erano disponibili per l'uso come fallback. Questa logica trattava un outage di comunicazione transitoria allo stesso modo di un errore di configurazione permanente, rendendo la cache fallback inutilizzabile esattamente al momento in cui era più necessario. Quando il componente di configurazione è diventato instabile, ogni pod che tenta di riavviare — sia a causa di pressione di memoria o autoscaling — è rimasto bloccato in un loop di fallimento, in grado di completare il processo di inizializzazione. # Risoluzione # Il team conteneva l'impatto iniziale isolando il traffico da uno dei componenti interessati, che ha fermato il picco di errore in circa 9 minuti. Seguiva la stabilizzazione del componente di gestione della configurazione, permettendo ai pod di tornare normalmente. Una correzione di emergenza è stata preparata e dispiegata lo stesso giorno, rimuovendo la validazione restrittiva che ha bloccato l'avvio — assicurando che la cache di fallback viene utilizzata in modo trasparente in situazioni simili che vanno avanti. # Lezioni imparate # L'incidente ha rivelato che il meccanismo di resilienza del servizio — la cache fallback — esisteva nell'architettura ma è stato neutralizzato dalla logica di avvio, che ha priorità la validazione rigorosa dei dati sulla disponibilità dell'ambiente. I percorsi di avvio per i servizi critici devono essere progettati per degradare con grazia quando i componenti di infrastruttura di supporto sono instabili, garantendo continuità operativa. **Commissione alla stabilità e al miglioramento continuo ** Continueremo a investire fortemente nella robustezza della nostra infrastruttura per garantire che i nostri servizi funzionino costantemente ai massimi livelli di efficienza, sicurezza e affidabilità. Squadra Unico.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 7 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 22:05 UTCidentified

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

3. 3 luglio 2026 alle ore 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 luglio 2026 alle ore 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 luglio 2026 alle ore 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 giugno 2026 alle ore 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 luglio 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 luglio 2026 alle ore 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 giugno 2026 alle ore 01:24 UTCinvestigating

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

2. 23 giugno 2026 alle ore 01:39 UTCidentified

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

3. 23 giugno 2026 alle ore 01:53 UTCidentified

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

4. 23 giugno 2026 alle ore 02:18 UTCmonitoring

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

5. 23 giugno 2026 alle ore 02:41 UTCresolved

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

6. 14 luglio 2026 alle ore 13:58 UTCpostmortem

   # Sommario # Il 22 giugno 2026, alle 21:52 \(Brasília time\), il flusso di salvataggio dei documenti non è disponibile a causa della esaurimento di un limite di identificazione sequenziale nel database. Da quel momento in poi, tutte le operazioni di inserimento dei documenti hanno cominciato a fallire, cascando errori a più servizi dipendenti. L'incidente durò circa 86 minuti. # Impatto # Diversi servizi critici sono stati colpiti simultaneamente — compresi i flussi di bordo, la creazione di processo, l'autenticazione e i pagamenti. In alcuni flussi, la disponibilità è scesa al di sotto del 3%. I clienti hanno avuto gli utenti colpiti da guasti o ritardi durante il tentativo di operazioni che dipendevano dal salvataggio dei documenti. ♪Root Cause ♪ La causa principale era legata al tipo di identificatore a 32 bit utilizzato nella tabella dei documenti, che supporta circa 2,1 miliardi di valori; con la crescita naturale del volume record nel tempo, questo limite è stato raggiunto, causando il database di non essere più in grado di generare nuovi identificatori, quindi tutte le operazioni di inserimento hanno cominciato a fallire. Poiché non vi era alcun monitoraggio configurato per monitorare la prossimità di questo limite, la stanchezza si è verificata bruscamente e senza preavviso. # Risoluzione # Il team ha identificato la causa principale in circa 20 minuti. Come mitigazione immediata, l'identificatore sequenziale è stato riconfigurato per utilizzare l'intervallo negativo dello stesso tipo di dati, liberando circa altri 2,1 miliardi di valori senza richiedere alcun cambiamento strutturale al database. La soluzione è stata validata in ambienti più bassi prima di essere applicata alla produzione. Il servizio ha cominciato a stabilizzarsi poco dopo l'applicazione della correzione e è stato monitorato fino a quando il recupero completo è stato confermato. # Lezioni imparate # L'incidente evidenzia l'importanza di implementare il monitoraggio per l'uso sequenziale dell'identificatore nelle tabelle ad alto volume, con avvisi anticipati che permettono di gestire l'esaurimento come manutenzione pianificata; adottando i tipi di identificatori a 8 byte dall'inizio per le tabelle con alto volume di scrittura, tra cui questo controllo nei processi di revisione degli schemi; e mappando e documentando le dipendenze critiche dei servizi di persistenza del nucleo, al fine di dimensionare l'impatto e priorizzare la comunicazione con gli incidenti futuri.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 19 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 luglio 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 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