Historia awarii Unico

Dear Client, We have identified an instability in the identity verification capability, generating an error in a small portion of IDCloud requests. Our engineering team is already mobilized for diagnosis and working to identify the root cause in order to normalize the service as soon as possible. At this time, the technical team is conducting detailed analysis in our data layer to mitigate the impact. We reinforce that further updates will be sent shortly.

Dear Client, Our engineering team has identified and implemented the actions to resolve the instability in the identity verification capability that was generating an error in a small portion of IDCloud requests. At this time, the technical team is conducting detailed analysis in our data layer and continues to monitor the environment. We reinforce that further updates will be sent shortly.

Executive Summary and Impact On July 13, 2026, we identified an instability in our identity verification capability, generating errors on a minimal portion of IDCloud requests, affecting multiple authentication flows. The issue was detected through automated availability alerts around 9:27 AM BRT, with a slight increase in errors already noticeable from approximately 8:00 AM BRT and a significant worsening starting around 9:07 AM BRT, reaching peak impact around 9:49 AM BRT. Root Cause and Resolution The root cause was identified as a gradual change applied to an internal authentication component, which caused a failure in session token signature validation. Once the root cause was confirmed, the engineering team reverted the change, and service availability returned to normal. The most critical phase of the impact lasted approximately 44 minutes. Commitment and Next Steps Engineering is evaluating improvements to the change-validation process for gradual rollouts affecting critical authentication components, including automatic rollback mechanisms in case of error spikes during this type of rollout. A detailed postmortem is expected to be shared internally as a next step.

We are currently experiencing instability in IDCLOUD capabilities. Our technical team is already investigating the root cause. We will provide updates as soon as more information becomes available.

We have identified an instability that may cause temporary downtime or latency in some of our core verification and risk analysis APIs. Affected Services: - Identity & Validation: Identity Verification, 1:1 Validation, Serpro Similarity Return - Risk & Fraud: Risk Score, Fraud Risk Classification - Documentation & Liveness: Document Reuse & Capture, Liveness Current Status & Next Steps: Our Engineering team is already fully engaged and investigating the root cause. We are working actively to isolate the behavior and restore normal operations as quickly as possible.

Current Status & Next Steps Mitigation actions have been successfully applied, and the system is now stable. At this time, our Engineering team remains actively monitoring the platform's performance to ensure continued stability and normal operations. Thank you for your patience and understanding during this incident. Your services should now be operating normally.

Executive Summary and Impact Between 1:21 PM and 2:16 PM (Brasília Time) on July 10, 2026, we identified a fluctuation in the availability of the process creation flow and related journeys, resulting in a temporary spike in the error rate of some of our main APIs. - Scope of Impact: The event exclusively affected the availability of certain journeys during this interval. Customers who did not experience an increase in their error rate during this period were not impacted. - Data Integrity: There was no compromise to the integrity or security of the processed information. - Mitigation: An initial workaround was applied within a few minutes, halting the volume of errors. The service was fully normalized at 2:16 PM, following stability confirmation from our Engineering and Monitoring teams. Root Cause The incident was triggered by instability in an infrastructure service, followed by a sudden degradation in the initialization of related internal components. Commitment and Next Steps We are deeply committed to the resilience of our platform. The corrective and preventive actions initiated during the incident are already being monitored to mitigate the risk of future occurrences of this nature. - Postmortem: A detailed technical report (Postmortem) will be shared soon, containing the complete timeline, architectural analysis, and a long-term action plan with defined deadlines. We sincerely apologize for the impact and instability caused. Our customers' trust is our highest priority, and we continue to work continuously to ensure the excellence of our services. Sincerely, Unico Team

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.

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!

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!

**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

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.

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!

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!

**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

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.

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

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

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

### **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.

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.

**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.

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

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!

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!

**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.

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

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

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

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!

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!

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.

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

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

**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.

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.

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

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

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

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.

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

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

Prezados clientes, Identificamos uma indisponibilidade técnica que afeta as principais funcionalidades da plataforma Unico Sign para clientes que utilizam Unico People Embora a página inicial possa carregar para alguns usuários, as funções internas do sistema (incluindo a gestão, consulta e processamento de envelopes e documentos) estão apresentando falhas e indisponibilidade no momento. Nossa equipe de engenharia já identificou a causa raiz e está atuando com máxima urgência e em regime de emergência na aplicação da correção para restabelecer os serviços o mais rápido possível. Pedimos sinceras desculpas pelo transtorno e manteremos todos atualizados sobre a aplicação da solução. Atenciosamente,

Prezados clientes, Gostaríamos de informar que a correção para a indisponibilidade na plataforma Unico Sign foi aplicada com sucesso. As principais funcionalidades do sistema já apresentam sinais de recuperação e estão retornando à normalidade. Nossa equipe de engenharia segue monitorando rigorosamente o ambiente para garantir que a estabilidade seja mantida de forma integral. Agradecemos a paciência de todos durante o processo. Traremos novas atualizações assim que o serviço estiver totalmente normalizado. Atenciosamente,

Prezados clientes, Informamos que o incidente de indisponibilidade na plataforma Unico Sign foi oficialmente encerrado. Após um período de monitoramento rigoroso pela nossa equipe de engenharia, confirmamos que todas as funcionalidades do sistema — incluindo a gestão, consulta e processamento de envelopes — foram totalmente restabelecidas e operam com estabilidade. Agradecemos sinceramente pela paciência e compreensão de todos durante o ocorrido. Atenciosamente,

Prezado Cliente, Nossa monitoração identificou um impacto no fluxo de criação de processos que utilizam o flow de Captura e Reaproveitamento de Documentos(IDDocs), afetando os processos integrados a essa capacidade, o problema ocorreu por volta das 15:50 finalizando por volta das 16:10 Nosso time de tecnologia está analisando o ambiente e em breve retornaremos com novas atualizações.

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!

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!

Prezado Cliente, Identificamos uma instabilidade na funcionalidade de criação de processos e fluxos de autenticação. Informamos que o impacto ocorreu pra uma parcela minima de clientes, de forma intermitente, por um periodo de aproximadamente 10 minutos.. Caso você não tenha notado elevação no número de erros durante este intervalo, sua operação consequentemente não foi afetada. Equipe Unico.

Informamos que o incidente iniciado às 22h02, que causou instabilidade nas requisições de criação de processos, foi normalizado às 22h12. Durante esse período houve uma degradação temporária de disponibilidade, sem perda de dados. O impacto ocorreu apenas para uma parcela reduzida de clientes. Nossa equipe atuou no acompanhamento e estabilização do ambiente, e os serviços já operam normalmente. Um postmortem detalhado será compartilhado posteriormente com mais informações sobre o ocorrido e os próximos passos. Pedimos desculpas pelos transtornos e agradecemos a compreensão. Equipe Unico.

Prezado Cliente, Detectamos um impacto nos retornos das requisições no fluxo do ByUnico e ByClient, gerando instabilidade aos clientes em uma parcela mínima de requisições Foram cerca de 814 erros durante o período de 11:10am até 11:16am, 2% das capturas com SDK que usa Liveness foram afetados neste período, é possível que o usuário na segunda tentativa de captura tenha passado com sucesso. O ambiente já está normalizado nesse momento, e estamos iniciando um monitoramento para garantir a saúde do sistema. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Foram cerca de 814 erros durante o período de 11:10am até 11:16am, sendo 2% das capturas com SDK que usa Liveness foram afetados neste período, é possível que o usuário na segunda tentativa de captura tenha passado com sucesso. 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!

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!

**Resumo** Em 19 de maio de 2026, entre 11h10 e 18h02 \(horário de Brasília\), o serviço de orquestração de liveness apresentou taxas de erro acima de 2%, gerando 814 erros em uma janela de 4 minutos. A causa foi um incidente de infraestrutura da nuvem que gerou latência extrema, impactando os nós que executavam as cargas de trabalho do serviço. A latência fez com que as sondas de saúde dos contêineres falhassem e os pods entrassem em ciclo de reinicialização, amplificado por um defeito conhecido no sandbox de execução que impedia a recuperação automática dos pods afetados. **Impacto** Usuários que utilizavam o fluxo de validação biométrica via SDK tiveram requisições negadas com erros de timeout \(504\). A taxa de erro atingiu mais de 2% durante o período de pico. A degradação se estendeu por um período mais longo do que o necessário devido ao defeito no mecanismo de recuperação dos contêineres, que manteve pods permanentemente impactados mesmo após a estabilização parcial da infraestrutura. **Causa Raiz** A causa raiz foi uma dependência externa: o provedor de infraestrutura de nuvem registrou um incidente ativo de latência em disco na zona us-east1-b, elevando a pressão de I/O nos nós afetados em aproximadamente 30 vezes acima do nível normal. Isso fez com que as respostas dos pods ultrapassassem o limite de timeout do proxy de serviço \(~8 segundos\), levando o orquestrador de contêineres a matar e reiniciar os pods. Um defeito conhecido no sandbox de execução impediu que alguns pods se recuperassem corretamente após os reinícios, transformando uma interrupção transitória em uma degradação prolongada. A equipe não possuía monitoramento de pressão de I/O nos nós de produção, nem integração entre os alertas de saúde da infraestrutura do provedor e os canais internos, o que atrasou significativamente a identificação da causa raiz. **Resolução** A equipe isolou o problema na zona us-east1-b por meio de análise comparativa entre clusters e zonas. A mitigação foi realizada drenando o pool de nós afetado e migrando as cargas de trabalho para um pool saudável. Após a migração, a latência voltou ao nível normal imediatamente, sem novas falhas nos 35 minutos seguintes. **Lições Aprendidas** * A ausência de monitoramento de pressão de I/O nos nós de produção tornou a degradação de infraestrutura completamente invisível até que ela se manifestasse como falhas na camada de aplicação. Implementar alertas de I/O com limiares adequados é a melhoria mais crítica identificada neste incidente. * Não havia integração entre os alertas de saúde de infraestrutura do provedor de nuvem e os canais internos de monitoramento. O incidente de I/O estava ativo há horas antes de ser descoberto manualmente pela equipe. * O defeito no sandbox de execução amplificou o impacto ao impedir a recuperação automática de pods afetados, transformando uma falha transitória em uma degradação sustentada. Esse risco permanece aberto até que o defeito seja corrigido na versão em uso. * A metodologia de investigação por eliminação comparativa — comparando comportamento entre clusters, pools de nós e zonas — foi altamente eficaz para isolar o problema e deve ser documentada como padrão de investigação para incidentes de infraestrutura.

Prezado Cliente, Identificamos um comportamento irregular nas capacidades de retorno do ByUnico e ByClient. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar como lentidão ou intermitência no serviço em uma parcela mínima de requisições. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações. Atenciosamente,

Prezado Cliente, Detectamos o motivo do impacto nos retornos das requisições no fluxo do ByUnico e ByClient, podendo causar instabilidade aos clientes. A equipe de tecnologia está ativamente analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

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!

Prezado Cliente, Confirmamos que o comportamento inesperado nos fluxos do ByUnico e ByClient foi totalmente resolvido e todos os serviços estão operando normalmente, com total estabilidade. Nossa equipe seguiu monitorando o ambiente após as correções e valida que o fluxo de requisições está regularizado. Conforme mencionado, compartilharemos nos próximos dias um Postmortem com o detalhamento do ocorrido. Agradecemos a paciência, pedimos desculpas pelo transtorno e seguimos à disposição através dos nossos canais de atendimento para qualquer dúvida. Atenciosamente, Equipe Unico

**Resumo** Em 18 de maio de 2026, entre 09h55 e 10h23 \(horário de Brasília\), a taxa de sucesso de conclusão de jornadas caiu abruptamente para todos os usuários. O impacto durou aproximadamente 28 minutos e afetou todos os fluxos de autenticação e cadastro via web. A causa foi uma implantação que introduziu uma mudança defeituosa e foi aplicada a 100% do tráfego sem rollout gradual. O rollback foi aplicado às 10h23 e o serviço voltou ao normal logo em seguida. **Impacto** Todos os usuários que utilizavam o fluxo de autenticação via web foram impactados. As jornadas ficaram travadas especialmente na etapa de validação facial — os usuários conseguiam iniciar o processo, mas não avançavam para a etapa de biometria. O volume de criação de processos manteve-se elevado enquanto o volume de conclusões caiu significativamente, com o throughput caindo de ~16-19 mil para ~6-8 mil requisições. O impacto foi generalizado para todos os clientes ativos em múltiplos fluxos. **Causa Raiz** A causa raiz foi um erro operacional: uma implantação realizada na manhã do incidente introduziu uma configuração defeituosa que corrompeu o comportamento do fluxo de validação facial. A implantação foi aplicada a 100% do tráfego de forma simultânea, sem estratégia de rollout gradual — o processo de implantação do SDK web não suporta releases em canário. Mudanças em arquivos de configuração também não estavam disparando processos automáticos de rollout/rollback como esperado pela equipe, pois esse comportamento só é acionado por chamadas específicas do frontend ao backend. Por fim, o indicador de qualidade do serviço para detecção dessa anomalia estava configurado com um limite de tolerância muito permissivo \(75% em 1 hora\), o que atrasou o alerta em aproximadamente 14 minutos após o início do impacto. **Resolução** A equipe identificou a implantação causadora por meio dos alertas de anomalia no indicador de qualidade do serviço. O rollback foi aplicado e o sistema começou a se recuperar imediatamente. Às 10h23, o fluxo retornou à normalidade e o incidente foi encerrado após confirmação de estabilidade. Os limites do indicador foram ajustados para 95% em 15 minutos após o incidente. **Lições Aprendidas** * A ausência de rollout gradual para o componente de SDK web fez com que 100% dos usuários fossem impactados imediatamente por uma mudança defeituosa. A implementação de estratégias de rollout gradual para esse componente é a melhoria de maior prioridade identificada. * Os limites de tolerância a falhas para o indicador de qualidade do serviço estavam configurados de forma muito permissiva \(75% em 1 hora\), resultando em um atraso de ~14 minutos na detecção. Os limites foram ajustados para valores mais restritivos \(95% em 15 minutos\). * Mudanças em arquivos de configuração não estavam disparando processos automáticos de rollout/rollback, contrariando a expectativa da equipe. Isso aumentou o tempo de resposta durante o incidente e representa um risco para situações futuras semelhantes. * A ausência de alertas orientados a jornadas do usuário no lado do cliente \(frontend\) fez com que a detecção dependesse exclusivamente de métricas de backend, que introduzem um atraso mínimo de 3 minutos por design. Alertas de jornadas críticas no frontend são uma lacuna urgente a ser endereçada.

Prezado Cliente, Identificamos um comportamento irregular nas capacidades de retorno do ByUnico e ByClient. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar como lentidão ou intermitência no serviço em uma parcela mínima de requisições. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações. Atenciosamente, Equipe Unico

Prezado Cliente, Detectamos o motivo do impacto nos retornos das requisições no fluxo do ByUnico e ByClient, podendo causar instabilidade aos clientes. A equipe de tecnologia está ativamente analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

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!

Prezado Cliente, Confirmamos que o comportamento inesperado nos fluxos do ByUnico e ByClient foi totalmente resolvido e todos os serviços estão operando normalmente, com total estabilidade. Nossa equipe seguiu monitorando o ambiente após as correções e valida que o fluxo de requisições está regularizado. Conforme mencionado, compartilharemos nos próximos dias um Postmortem com o detalhamento do ocorrido. Agradecemos a paciência, pedimos desculpas pelo transtorno e seguimos à disposição através dos nossos canais de atendimento para qualquer dúvida. Atenciosamente, Equipe Unico

**Resumo** Em 18 de maio de 2026, entre 09h55 e 10h23 \(horário de Brasília\), a taxa de sucesso de conclusão de jornadas caiu abruptamente para todos os usuários. O impacto durou aproximadamente 28 minutos e afetou todos os fluxos de autenticação e cadastro via web. A causa foi uma implantação que introduziu uma mudança defeituosa e foi aplicada a 100% do tráfego sem rollout gradual. O rollback foi aplicado às 10h23 e o serviço voltou ao normal logo em seguida. **Impacto** Todos os usuários que utilizavam o fluxo de autenticação via web foram impactados. As jornadas ficaram travadas especialmente na etapa de validação facial — os usuários conseguiam iniciar o processo, mas não avançavam para a etapa de biometria. O volume de criação de processos manteve-se elevado enquanto o volume de conclusões caiu significativamente, com o throughput caindo de ~16-19 mil para ~6-8 mil requisições. O impacto foi generalizado para todos os clientes ativos em múltiplos fluxos. **Causa Raiz** A causa raiz foi um erro operacional: uma implantação realizada na manhã do incidente introduziu uma configuração defeituosa que corrompeu o comportamento do fluxo de validação facial. A implantação foi aplicada a 100% do tráfego de forma simultânea, sem estratégia de rollout gradual — o processo de implantação do SDK web não suporta releases em canário. Mudanças em arquivos de configuração também não estavam disparando processos automáticos de rollout/rollback como esperado pela equipe, pois esse comportamento só é acionado por chamadas específicas do frontend ao backend. Por fim, o indicador de qualidade do serviço para detecção dessa anomalia estava configurado com um limite de tolerância muito permissivo \(75% em 1 hora\), o que atrasou o alerta em aproximadamente 14 minutos após o início do impacto. **Resolução** A equipe identificou a implantação causadora por meio dos alertas de anomalia no indicador de qualidade do serviço. O rollback foi aplicado e o sistema começou a se recuperar imediatamente. Às 10h23, o fluxo retornou à normalidade e o incidente foi encerrado após confirmação de estabilidade. Os limites do indicador foram ajustados para 95% em 15 minutos após o incidente. **Lições Aprendidas** * A ausência de rollout gradual para o componente de SDK web fez com que 100% dos usuários fossem impactados imediatamente por uma mudança defeituosa. A implementação de estratégias de rollout gradual para esse componente é a melhoria de maior prioridade identificada. * Os limites de tolerância a falhas para o indicador de qualidade do serviço estavam configurados de forma muito permissiva \(75% em 1 hora\), resultando em um atraso de ~14 minutos na detecção. Os limites foram ajustados para valores mais restritivos \(95% em 15 minutos\). * Mudanças em arquivos de configuração não estavam disparando processos automáticos de rollout/rollback, contrariando a expectativa da equipe. Isso aumentou o tempo de resposta durante o incidente e representa um risco para situações futuras semelhantes. * A ausência de alertas orientados a jornadas do usuário no lado do cliente \(frontend\) fez com que a detecção dependesse exclusivamente de métricas de backend, que introduzem um atraso mínimo de 3 minutos por design. Alertas de jornadas críticas no frontend são uma lacuna urgente a ser endereçada.

Prezado Cliente, Nossa monitoração proativa detectou um comportamento irregular nas capacidades de retorno do ByUnico e ByClient. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar como lentidão ou intermitência no serviço em uma parcela mínima de requisições. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações. Atenciosamente, Equipe Unico

Prezado Cliente, Detectamos o motivo do impacto nos retornos das requisições no fluxo do ByUnico e ByClient, podendo causar instabilidade aos clientes. A equipe de tecnologia está ativamente analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

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!

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!

**Resumo** Em 18 de maio de 2026, entre 09h55 e 10h23 \(horário de Brasília\), a taxa de sucesso de conclusão de jornadas caiu abruptamente para todos os usuários. O impacto durou aproximadamente 28 minutos e afetou todos os fluxos de autenticação e cadastro via web. A causa foi uma implantação que introduziu uma mudança defeituosa e foi aplicada a 100% do tráfego sem rollout gradual. O rollback foi aplicado às 10h23 e o serviço voltou ao normal logo em seguida. **Impacto** Todos os usuários que utilizavam o fluxo de autenticação via web foram impactados. As jornadas ficaram travadas especialmente na etapa de validação facial — os usuários conseguiam iniciar o processo, mas não avançavam para a etapa de biometria. O volume de criação de processos manteve-se elevado enquanto o volume de conclusões caiu significativamente, com o throughput caindo de ~16-19 mil para ~6-8 mil requisições. O impacto foi generalizado para todos os clientes ativos em múltiplos fluxos. **Causa Raiz** A causa raiz foi um erro operacional: uma implantação realizada na manhã do incidente introduziu uma configuração defeituosa que corrompeu o comportamento do fluxo de validação facial. A implantação foi aplicada a 100% do tráfego de forma simultânea, sem estratégia de rollout gradual — o processo de implantação do SDK web não suporta releases em canário. Mudanças em arquivos de configuração também não estavam disparando processos automáticos de rollout/rollback como esperado pela equipe, pois esse comportamento só é acionado por chamadas específicas do frontend ao backend. Por fim, o indicador de qualidade do serviço para detecção dessa anomalia estava configurado com um limite de tolerância muito permissivo \(75% em 1 hora\), o que atrasou o alerta em aproximadamente 14 minutos após o início do impacto. **Resolução** A equipe identificou a implantação causadora por meio dos alertas de anomalia no indicador de qualidade do serviço. O rollback foi aplicado e o sistema começou a se recuperar imediatamente. Às 10h23, o fluxo retornou à normalidade e o incidente foi encerrado após confirmação de estabilidade. Os limites do indicador foram ajustados para 95% em 15 minutos após o incidente. **Lições Aprendidas** * A ausência de rollout gradual para o componente de SDK web fez com que 100% dos usuários fossem impactados imediatamente por uma mudança defeituosa. A implementação de estratégias de rollout gradual para esse componente é a melhoria de maior prioridade identificada. * Os limites de tolerância a falhas para o indicador de qualidade do serviço estavam configurados de forma muito permissiva \(75% em 1 hora\), resultando em um atraso de ~14 minutos na detecção. Os limites foram ajustados para valores mais restritivos \(95% em 15 minutos\). * Mudanças em arquivos de configuração não estavam disparando processos automáticos de rollout/rollback, contrariando a expectativa da equipe. Isso aumentou o tempo de resposta durante o incidente e representa um risco para situações futuras semelhantes. * A ausência de alertas orientados a jornadas do usuário no lado do cliente \(frontend\) fez com que a detecção dependesse exclusivamente de métricas de backend, que introduzem um atraso mínimo de 3 minutos por design. Alertas de jornadas críticas no frontend são uma lacuna urgente a ser endereçada.

Prezado cliente, Identificamos uma instabilidade no acesso aos portais de nossos produtos, que podem se manifestar como um timeout ou em um erro ao fazer o acesso. Nosso time de engenharia está atuando na normalização do serviço.

We are continuing to investigate this issue.

Prezado Cliente, Gostaríamos de fornecer uma atualização sobre o incidente. Nosso time de tecnologia permanece atuando na correção da instabilidade mencionada anteriormente. Reforçamos os seguintes pontos: - O Impacto está ocorrendo no acesso aos nossos Portais Unico, afetando o PortalID, UnicoPeople e IDSign - As requisições via API seguem operando normalmente As ações corretivas seguem em execução acelerada para restabelecer a estabilidade plena o quanto antes. Reiteramos nosso compromisso com a transparência e enviaremos novas informações assim que o cenário for normalizado. Atenciosamente, Equipe Unico

Prezado Cliente, Gostaríamos de fornecer uma atualização sobre o incidente. Nosso time de tecnologia permanece atuando na correção da instabilidade mencionada anteriormente. Reforçamos os seguintes pontos: - O portalID, UnicoPeople e IDSign não está mais impactados e no momento está operacional - Algumas funcionalidades do portal IDsign e UnicoPeople seguem impactadas - As requisições via API seguem operando normalmente - Identificamos também uma instabilidade na entrega dos links via SMS e Whatsapp. As ações corretivas seguem em execução acelerada para restabelecer a estabilidade plena o quanto antes. Reiteramos nosso compromisso com a transparência e enviaremos novas informações assim que o cenário for normalizado. Atenciosamente, Equipe Unico

Prezado cliente. Identificamos a causa da instabilidade nos portais e nos disparo dos links e aplicamos as devidas correções. No momento estamos dando inicio à fase de operação assistida. Atenciosamente, Equipe Unico

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.

**Resumo** Em 18 de maio de 2026, entre 08h17 e 11h16 \(horário de Brasília\), o portal de acesso dos usuários ficou inacessível por aproximadamente 3 horas, com taxas de erro no endpoint de perfil atingindo entre 80% e 97%. O incidente foi causado pela saturação de disco em um componente de infraestrutura de filas de mensagens, que ao atingir o limite configurado bloqueou automaticamente todos os publicadores de mensagens. O alerta de disco havia sido disparado na sexta-feira anterior, mas foi enviado apenas para um único endereço de e-mail e não chegou à equipe de plantão, permitindo que o problema se agravasse ao longo do final de semana. **Impacto** Todos os usuários do portal enfrentaram timeouts de login e erros 502 durante o período. Além do portal, outros produtos que dependiam do mesmo serviço de identidade foram afetados, incluindo fluxos de criação de novos usuários, reset de senha e login em outros sistemas internos. **Causa Raiz** A causa raiz foi a saturação do espaço em disco de um dos nós do cluster de filas de mensagens. Quando o espaço livre caiu abaixo do limite configurado, o próprio sistema ativou automaticamente um bloqueio de publicação de mensagens como mecanismo de proteção contra perda de dados. Com o bloqueio ativo, um componente intermediário da rota de autenticação passou a enfileirar requisições em vez de processá-las, gerando latências de até 23 segundos nas chamadas de autenticação. O alerta havia sido emitido na sexta-feira às 10h16 — três dias antes da interrupção — mas estava configurado para notificar apenas um único endereço de e-mail não monitorado ativamente, o que permitiu que a condição persistisse sem intervenção durante todo o final de semana. **Resolução** A equipe identificou o problema no cluster de filas de mensagens às 11h05. Foram realizados o reinício do cluster e a expansão do disco. Após essas ações, a latência retornou ao normal às 11h15 e todos os serviços afetados se estabilizaram. **Lições Aprendidas** * O alerta de saturação de disco do cluster de filas de mensagens estava configurado para notificar apenas um único endereço de e-mail, sem envio para canais monitorados ativamente ou para a escala de plantão. O alerta disparou em uma sexta-feira e passou despercebido até segunda-feira, quando a saturação já havia causado uma interrupção generalizada. Expandir a cobertura de alertas de infraestrutura crítica para canais ativamente monitorados é a melhoria mais urgente identificada. * O componente de filas de mensagens era compartilhado entre múltiplos serviços — autenticação, portal e notificações via webhook — sem isolamento. A saturação de disco de um único nó causou impacto simultâneo em todos esses serviços. A segregação da infraestrutura de filas por domínio reduziria significativamente o raio de impacto de falhas futuras. * Não havia mecanismo automatizado de expansão de disco ou rotação de logs quando o uso se aproximasse do limite configurado. A dependência de intervenção manual após um alerta que não foi visto deixou o sistema vulnerável durante o final de semana. * O tempo total para identificação da causa raiz foi de aproximadamente 3 horas. A ausência de painéis ou runbooks que correlacionassem a saúde do cluster de filas de mensagens com a degradação dos serviços dependentes contribuiu para que a investigação inicial seguisse caminhos incorretos antes de convergir para o componente correto.

Prezado Cliente, Identificamos uma instabilidade pontual em nossos serviços que pode gerar impacto na disponibilidade de uma parcela mínima de nossas requisições para o produto ID Pay. Informamos que as ações corretivas estão sendo executadas para minimizar grandes impactos. Caso não tenha observado degradação em seu ambiente, não houve impacto em sua operação. Reforçamos nosso compromisso com a transparência e enviaremos novas atualizações assim que houver novidades. Atenciosamente, Equipe Unico

Prezado Cliente, Nosso time de tecnologia segue trabalhando para resolver a instabilidade em nossos serviços que gerou impacto na disponibilidade de uma parcela mínima de nossas requisições para o produto ID Pay. Informamos que as ações corretivas estão sendo executadas para minimizar grandes impactos. Caso não tenha observado degradação em seu ambiente, não houve impacto em sua operação. Reforçamos nosso compromisso com a transparência e enviaremos novas atualizações assim que houver novidades. Atenciosamente, Equipe Unico

Prezado Cliente, Gostaríamos de fornecer uma atualização sobre o status do produto ID Pay. Nosso time de tecnologia permanece atuando na correção da instabilidade mencionada anteriormente. Reforçamos os seguintes pontos: - Impacto Parcial: A intermitência está restrita a uma funcionalidade específica, não afetando a totalidade do ecossistema. - Baixo Volume: O incidente atinge um volume muito reduzido de requisições, o que significa que a vasta maioria das transações segue processada normalmente. - Operação Preservada: Caso você não tenha observado qualquer degradação em seu ambiente até o momento, sua operação permanece íntegra e sem impactos. As ações corretivas seguem em execução acelerada para restabelecer a estabilidade plena o quanto antes. Reiteramos nosso compromisso com a transparência e enviaremos novas informações assim que o cenário for normalizado. Atenciosamente, Equipe Unico

Prezado Cliente, Informamos que as ações corretivas foram executadas com sucesso e o ambiente já apresenta estabilidade. Neste momento, nossas equipes de engenharia e operações iniciaram um período de monitoramento rigoroso e acompanhamento assistido de indicadores para garantir a consistência da performance em toda a nossa malha de serviços. Reforçamos nosso compromisso com a transparência e enviaremos novas atualizações assim que houver novidades. Dentro de alguns dias disponibilizaremos um postmortem detalhando as causas e ações de melhoria contínua. Atenciosamente, Equipe Unico

Prezado Cliente, Incidente resolvido. Informamos que as ações corretivas foram executadas com sucesso e o ambiente já apresenta estabilidade. Neste momento, nossas equipes de engenharia e operações iniciaram um período de monitoramento rigoroso e acompanhamento assistido de indicadores para garantir a consistência da performance em toda a nossa malha de serviços. Dentro de alguns dias disponibilizaremos um postmortem detalhando as causas e ações de melhoria contínua. Atenciosamente, Equipe Unico

**Resumo** Em 15 de maio de 2026, entre 08h08 e 08h44 \(horário de Brasília\), a função de definição de retenção de pagamentos \(Hold Definition\) do serviço de pagamentos apresentou queda de disponibilidade na camada de borda, com aproximadamente 71 transações falhando — uma taxa de erro de 1,4%. O incidente foi causado por uma interrupção geral em um provedor externo de Open Finance, que passou a retornar erros 500 para todos os seus consumidores. A mitigação foi realizada por meio de uma feature flag que desabilitou temporariamente a integração com o provedor afetado. **Impacto** Usuários que utilizavam o fluxo de validação de transações via Open Finance não conseguiram completar suas operações durante o período. Transações já em andamento continuaram falhando mesmo após a ativação da feature flag, pois a desabilitação não cobria fluxos intermediários. A desativação do provedor também reduziu temporariamente a taxa de aprovação de transações, que passaram a retornar status "indeterminado" em vez de aprovação definitiva. **Causa Raiz** A causa raiz foi uma dependência externa: o provedor de Open Finance sofreu uma interrupção generalizada em sua API pública, retornando erros 5xx para todos os consumidores. A plataforma possui um circuit breaker para a etapa de geração de links, que funcionou para novas transações. No entanto, transações já em andamento continuaram sendo roteadas ao provedor durante o período de instabilidade prolongada, pois o circuit breaker não cobria todos os estados do fluxo. A dependência exclusiva de um único provedor para validação via Open Finance, sem rota alternativa, amplificou o impacto. **Resolução** A equipe identificou o provedor externo como fonte do problema em poucos minutos. A feature flag de desabilitação foi ativada, contendo o impacto em novas transações. Após confirmação do provedor de que um fix havia sido implementado e estabilizado, a integração foi reativada. **Lições Aprendidas** * O circuit breaker existente cobre apenas a etapa de geração de links, não todos os estados do fluxo transacional. Durante instabilidade prolongada do fornecedor, transações em andamento continuaram falhando. Um mecanismo de isolamento completo cobrindo todos os estados transacionais é necessário para minimizar o impacto em cenários semelhantes. * A dependência exclusiva de um único provedor para validação via Open Finance representa um risco estrutural: qualquer interrupção do fornecedor impacta diretamente a disponibilidade para os usuários. Avaliar redundância ou rotas alternativas para este fluxo é a principal melhoria estrutural identificada.