Unico Outage History

Started Aug 30, 2026, 03:15 AM UTC· resolved Aug 30, 2026, 03:15 AM UTC

1. investigating Aug 31, 2026, 12:41 PM UTC

   Dear Customer, At approximately 11:00 PM (BRT) on Friday, August 29, 2026, we identified an instability affecting process creation in IDCloud. During this period, some requests may fail or experience slower than usual response times. We recognize the inconvenience this may cause and appreciate your understanding. A new update will be provided shortly. Unico Team

2. monitoring Aug 31, 2026, 12:41 PM UTC

   Dear Customer, Our engineering team has carried out the corrective actions required to resolve the instability affecting process creation in IDCloud. The environment has returned to stability, with availability and response-time indicators restored to normal operating levels as of 11:48 PM (BRT). The service is available for normal use. At this time, our technical team remains under assisted monitoring, closely watching the environment to ensure consistent performance and to act immediately in case of any fluctuation. We appreciate your understanding and reiterate that further updates will be sent shortly. Unico Team

3. identified Aug 31, 2026, 12:41 PM UTC

   Our engineering team has mapped the origin of the instability affecting process creation in IDCloud. The technical team has already begun applying corrective measures, including scaling resources in the affected layer and continuously monitoring key indicators. Restoring the service is being handled with top priority and full engineering mobilization. We reiterate that further updates will be sent shortly. Unico Team

4. resolved Aug 31, 2026, 12:41 PM UTC

   Dear Customer, Executive Summary and Impact Between 11:00 PM and 11:48 PM (BRT) on August 29, 2026, an outage affected process creation in IDCloud. During this window, some customers using these flows experienced failures and increased response times, with propagation to dependent journeys including authentication, document capture, and notification delivery. There was no compromise to the integrity or security of the processed information, and no data was lost. Indicators returned to normal operating levels at 11:48 PM (BRT), with normalization confirmed both in our monitoring and on the customer side, covering process creation and completion. Root Cause and Resolution The origin was identified in our data layer: an internal maintenance routine became stuck, and application operations began queuing behind it until the available connection limit was exhausted, reducing processing capacity. Our engineering team surgically terminated only the stuck routine, immediately releasing the queue. Connections and processing capacity were fully restored, with no data changes. Commitment and Next Steps Our engineering team will focus on three fronts: limiting wait times for internal maintenance routines, preventing concurrent routines from running against the same structure, and strengthening service resilience to fluctuations in the data layer. A detailed postmortem, including the complete timeline and an action plan with deadlines, will be shared shortly. We sincerely apologize for the impact on your operations and remain available through our support channels. Unico Team

Read the full incident report →

Started Aug 10, 2026, 09:01 PM UTC· resolved Aug 10, 2026, 09:01 PM UTC

1. identified Aug 28, 2026, 09:26 PM UTC

   Dear customer, We have detected an impact on some IDCloud requests, affecting Behavior Alert (IDTrust) capability and the 1:N flow. This instability may also affect customers in Mexico who use this capability. Our engineering team is mobilized to resolve the issue as soon as possible. We will provide new updates shortly.

2. resolved Aug 28, 2026, 09:26 PM UTC

   Executive Summary and Impact Around 5:08 PM, an automated alert detected an availability drop in the facial recognition service (1:N flow), triggering the incident. The issue escalated quickly and began affecting the behavior alerting service and, subsequently, the process creation flow, due to cascading timeouts between these services. The impact affected a subset of clients using these capabilities. The situation was reported as stabilized at 5:22 PM, with metrics returning to normal levels. Root Cause and Resolution The root cause was a traffic spike generated by an internal workload, which sent a high volume of facial recognition requests directly into the biometric pipeline, bypassing the edge layer used by normal client traffic. This additional volume saturated the capacity of the database supporting the facial recognition service. The saturation caused timeouts in that service, which cascaded to the biometric engine orchestration service, then to the behavior alerting service, and finally to the process creation flow using these capabilities. To resolve the issue, the team stopped the workload responsible for the spike and increased the capacity of the affected database. These actions mitigated the problem, with error volume returning to near-zero levels. Commitment and Next Steps A follow-up item was opened to implement rate limiting for the type of internal workload that caused the spike, as a preventive measure against recurrence. The capacity increase for the affected database was already carried out during the incident itself.

3. monitoring Aug 28, 2026, 09:26 PM UTC

   Our engineering team has identified and implemented the necessary actions to resolve the instability in the affected IDCloud flow capabilities. At this time, the technical team is conducting a detailed analysis of our data layer and continues to monitor the environment. We reiterate that further updates will be sent shortly.

4. resolved Aug 28, 2026, 09:26 PM UTC

   On August 10, 2026, between 5:08 PM and 5:27 PM \(Brasília time\), the availability indicator for the 1:N facial recognition flow dropped below 95%, with a total impact of approximately 19 minutes. The incident was caused by saturation of the vector search database used by the biometric engine, resulting from unexpected behavior in the queue consumption mechanism, which generated a call volume 2.36 times higher than configured. The excess load reached the database's maximum scaling limit, causing cascading timeouts across multiple dependent services and affecting 55 client users with errors during the period. Users of the facial recognition, authentication, and process creation flows from multiple clients experienced errors and timeouts during the period. The database saturation cascaded through the biometric orchestration, engine, and process creation services. Mitigation was carried out by disabling an internal service and increasing the database's maximum scaling limit, stabilizing the service at 5:27 PM. The root cause was a combination of factors related to service behavior and the capacity of the infrastructure involved. The service was configured with a limit of 2 requests per second, but the queue consumption mechanism behaved unexpectedly: messages whose processing exceeded the acknowledgment deadline were redelivered by the queue without canceling the original execution — turning 938 work items into 2,217 effective calls \(~8.4 RPS\). This amplified traffic reached the database without passing through the edge protection layer, which would normally limit request volume, since the network path used in this flow did not go through those controls. The database, already operating close to its maximum scaling limit, was unable to absorb the additional load — its CPU reached 88% while scaling up to the configured ceiling of 100 nodes — and query latency jumped from ~3 seconds to ~18.75 seconds at p90, propagating timeouts across the entire chain of dependent services. The team identified the process in question as the source of the load within a few minutes of the alert. The process was disabled, and the database's maximum scaling limit was increased from 100 to 150 nodes. With these two actions, the service stabilized at 5:27 PM. The incident showed that rate limiting applied only on the message publishing side is insufficient when the consumer can amplify volume through redelivery. Rate and concurrency controls need to exist on the consumption side as well. Additionally, internal services that access critical components through paths that bypass edge protections represent a structural risk — any internal client can generate uncontrolled load on shared infrastructure.

Read the full incident report →

Started Jul 31, 2026, 02:06 PM UTC· resolved Jul 31, 2026, 02:06 PM UTC

1. monitoring Aug 28, 2026, 06:21 PM UTC

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

2. identified Aug 28, 2026, 06:21 PM UTC

   Prezados clientes, 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. No momento, os engenheiros já estão subindo a correção para restabelecer a exibição correta de todos os envios na interface do remetente. Lembramos que o processamento, envio e assinatura dos documentos continuam operando normalmente. Volataremos com uma nova atualização assim que a correção for concluída e entrarmos na fase de monitoramento. Atenciosamente,

3. investigating Aug 28, 2026, 06:21 PM UTC

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

4. resolved Aug 28, 2026, 06:21 PM UTC

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

Read the full incident report →

Started Jul 29, 2026, 02:04 PM UTC· resolved Jul 29, 2026, 02:04 PM UTC

1. resolved Aug 28, 2026, 06:21 PM UTC

   Executive Summary & Impact We would like to inform you that the incident temporarily affecting the ID Cloud Webhook notification service has been resolved. Impact Period: From 08:32 to 10:05. Platform Impact: The instability was strictly limited to Webhook notification delivery, resulting in a delay in message distribution. There was no degradation of the main platform, no failures in the liveness engine, and no data loss. Customer Impact: The issue affected a small portion of customers. Clients who have implemented a GET polling flow as a contingency (fallback) experienced no downtime or operational impact. Root Cause & Resolution Root Cause: The instability was triggered by a feature update in the environment. A temporary mismatch in access permissions between the task queue and the destination route caused requests to be denied, leading to a temporary backlog of notifications. Resolutive Action: The technical team completed the traffic redirection to the new environment, restoring proper communication between components and releasing the backlog of Webhooks. Processing has returned to normal, and the dispatch queue has been fully cleared. Commitment & Next Steps The stability of our services is our highest priority. To ensure total transparency and prevent recurrence, our engineering team will focus on the following fronts: Detailed Postmortem: A comprehensive report featuring an in-depth root cause analysis and a preventive action plan will be prepared. Observability Improvements: We will adjust monitoring metrics to ensure greater visibility into inter-service communication errors during transition scenarios. We sincerely apologize for the inconvenience and remain available for any further clarifications. Sincerely, Unico Team

Read the full incident report →

Started Jul 24, 2026, 10:18 PM UTC· resolved Jul 24, 2026, 10:18 PM UTC

1. resolved Aug 28, 2026, 06:21 PM UTC

   Executive Summary and Impact Starting at 6:05 PM (Brasília time), an instability occurred in the Webhook service, leading to failure in event processing and notification delivery for affected operations during this period. Root Cause and Resolution The incident was caused by an issue with a shared Service Account used across multiple services, resulting in authentication failures. Upon identifying the root cause, the engineering team restored the required credentials and configuration. Normal operation was fully re-established at 6:29 PM (BRT). Commitment and Next Steps As part of continuous improvement and risk mitigation, the engineering team will review resource dependencies and access management across services. This will prevent similar configuration issues in future infrastructure adjustments.

2. monitoring Aug 28, 2026, 06:21 PM UTC

   Dear Customer, Our engineering team has identified and implemented the necessary actions to resolve the Webhook instability affecting data delivery latency. At this time, the technical team is conducting a detailed analysis of our data layer and continues to monitor the environment. We reiterate that further updates will be sent shortly.

3. investigating Aug 28, 2026, 06:21 PM UTC

   Dear Customer, We are currently investigating an instability in our Webhooks that is affecting latency in data delivery. Our engineering team is actively working to resolve the issue as quickly as possible. We will provide further updates shortly.

Read the full incident report →

Started Jul 16, 2026, 03:28 PM UTC· resolved Jul 16, 2026, 03:28 PM UTC

1. investigating Aug 28, 2026, 06:21 PM UTC

   Dear Customer, We are investigating an instability in our authentication system for the Unico People portals and are also assessing issues in our messaging service affecting IDCloud customers. Our engineering team is mobilized to resolve the issue as soon as possible. We will provide updates shortly.

2. resolved Aug 28, 2026, 06:21 PM UTC

   Executive Summary and Impact At 10:51 AM on 07/16/2026, an issue was identified in the authentication service on the Unico People admission portal and in messaging, which affected the delivery of SMS and email links to Unico People and IDCloud clients, as well as B2C client authentication on the Unico People admission portal. The impact was limited to these two flows and did not affect the product's core critical journey. The incident lasted approximately 30 minutes until full resolution. Root Cause and Resolution The root cause was identified as storage pressure on one node of the messaging cluster, which reached a critical disk threshold, degrading the processing of queues responsible for message delivery and authentication. The engineering team increased the cluster's storage capacity at approximately 10:59 AM, which allowed queues and monitoring indicators to normalize within minutes. The environment was monitored until full recovery was confirmed, and the incident was closed at 11:20 AM. Commitment and Next Steps The engineering team will review alert escalation and prioritization criteria for this type of degradation, since the alerts correctly identified the issue, but the automatic escalation flow to the responsible team can be improved. A detailed postmortem is being prepared and will be shared in the coming days.

3. monitoring Aug 28, 2026, 06:21 PM UTC

   Dear Customer, Our team identified the issue and took action to resolve the incident. We experienced an instability in our authentication system for the Unico People portals, as well as issues in our messaging service affecting customers in the IDCloud flow, for SMS and email delivery. Our engineering team remains mobilized, monitoring the environment to ensure it continues functioning properly.

Read the full incident report →

Started Jul 07, 2026, 09:22 PM UTC· resolved Jul 07, 2026, 10:14 PM UTC

1. identified Jul 07, 2026, 09:22 PM UTC

   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. monitoring Jul 07, 2026, 09:32 PM UTC

   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. resolved Jul 07, 2026, 10:14 PM UTC

   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. postmortem Jul 13, 2026, 09:18 PM UTC

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

Read the full incident report →

Started Jul 06, 2026, 04:20 PM UTC· resolved Jul 06, 2026, 05:25 PM UTC

1. identified Jul 06, 2026, 04:29 PM UTC

   Prezado Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade com orquestração com Score de risco, que está apresentando lentidão no processamento de fluxos assíncronos. Essa oscilação pode impactar o tempo de recebimento das respostas de análise e, em alguns casos, resultar no cancelamento de processos em aberto. 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. monitoring Jul 06, 2026, 04:51 PM UTC

   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. resolved Jul 06, 2026, 05:25 PM UTC

   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. postmortem Jul 13, 2026, 09:17 PM UTC

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

Read the full incident report →

Started Jul 02, 2026, 10:04 PM UTC· resolved Jul 03, 2026, 01:14 AM UTC

1. identified Jul 02, 2026, 10:04 PM UTC

   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. identified Jul 02, 2026, 10:05 PM UTC

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

3. monitoring Jul 03, 2026, 12:04 AM UTC

   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. resolved Jul 03, 2026, 01:14 AM UTC

   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. postmortem Jul 13, 2026, 08:36 PM UTC

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

Read the full incident report →

Started Jun 26, 2026, 03:30 AM UTC· resolved Jun 26, 2026, 03:30 AM UTC

1. resolved Jun 26, 2026, 02:10 PM UTC

   Prezado cliente, Entre 00:17 e 10:40 de 26/06, identificamos uma instabilidade temporária que causou falhas de acesso e indisponibilidade 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. postmortem Jul 03, 2026, 06:22 PM UTC

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

Read the full incident report →

Started Jun 24, 2026, 06:20 PM UTC· resolved Jun 24, 2026, 06:53 PM UTC

1. identified Jun 24, 2026, 06:20 PM UTC

   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. monitoring Jun 24, 2026, 06:31 PM UTC

   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. resolved Jun 24, 2026, 06:53 PM UTC

   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. postmortem Jul 13, 2026, 07:27 PM UTC

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

Read the full incident report →

Started Jun 23, 2026, 01:24 AM UTC· resolved Jun 23, 2026, 02:41 AM UTC

1. investigating Jun 23, 2026, 01:24 AM UTC

   Prezado Cliente, Nossa monitoração proativa detectou um comportamento irregular no fluxo de onboarding (ByUnico e IDpay). 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.

2. identified Jun 23, 2026, 01:39 AM UTC

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

3. identified Jun 23, 2026, 01:53 AM UTC

   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.

4. monitoring Jun 23, 2026, 02:18 AM UTC

   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!

5. resolved Jun 23, 2026, 02:41 AM UTC

   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!

6. postmortem Jul 14, 2026, 01:58 PM UTC

   **Summary** On June 22, 2026, at 9:52 PM \(Brasília time\), the document saving flow became unavailable due to the exhaustion of a sequential identifier limit in the database. From that moment on, all document insertion operations began to fail, cascading errors to multiple dependent services. The incident lasted approximately 86 minutes. ‌ **Impact** Multiple critical services were affected simultaneously — including onboarding flows, process creation, authentication, and payments. In some flows, availability dropped to below 3%. Clients had users impacted by failures or delays when attempting operations that depended on document saving. ‌ **Root Cause** The root cause was related to the 32-bit identifier type used in the documents table, which supports approximately 2.1 billion values; with the natural growth in record volume over time, this limit was reached, causing the database to no longer be able to generate new identifiers, so all insertion operations began to fail. Since there was no monitoring configured to track proximity to this limit, the exhaustion occurred abruptly and without prior warning. ‌ **Resolution** The team identified the root cause in approximately 20 minutes. As an immediate mitigation, the sequential identifier was reconfigured to use the negative range of the same data type, freeing up approximately another 2.1 billion values without requiring any structural change to the database. The solution was validated in lower environments before being applied to production. The service began stabilizing shortly after the fix was applied and was monitored until full recovery was confirmed. ‌ **Lessons Learned** The incident highlights the importance of implementing monitoring for sequential identifier usage in high-volume tables, with early alerts that allow exhaustion to be handled as planned maintenance; adopting 8-byte identifier types from the outset for tables with high write volume, including this check in schema review processes; and mapping and documenting the critical dependencies of core persistence services, in order to size the impact and prioritize communication with affected users more quickly in future incidents.

Read the full incident report →

Started Jun 12, 2026, 03:00 PM UTC· resolved Jun 12, 2026, 06:31 PM UTC

1. identified Jun 12, 2026, 03:29 PM UTC

   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. identified Jun 12, 2026, 05:03 PM UTC

   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. monitoring Jun 12, 2026, 06:17 PM UTC

   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. resolved Jun 12, 2026, 06:31 PM UTC

   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

Read the full incident report →

Started Jun 11, 2026, 04:27 PM UTC· resolved Jun 11, 2026, 07:13 PM UTC

1. identified Jun 11, 2026, 04:27 PM UTC

   Prezados clientes, Identificamos uma indisponibilidade técnica que afeta as principais funcionalidades da plataforma Unico Sign. 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,

2. monitoring Jun 11, 2026, 05:51 PM UTC

   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,

3. resolved Jun 11, 2026, 07:13 PM UTC

   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,

Read the full incident report →

Started Jun 02, 2026, 06:55 PM UTC· resolved Jun 02, 2026, 07:25 PM UTC

1. identified Jun 02, 2026, 07:19 PM UTC

   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.

2. monitoring Jun 02, 2026, 07:21 PM UTC

   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. resolved Jun 02, 2026, 07:25 PM UTC

   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. postmortem Jul 20, 2026, 08:01 PM UTC

   Public Postmortem: Outage in the Process Creation Flow **Incident date:** June 2, 2026 **Total duration:** 9 minutes **Executive Summary** On June 2, 2026, the process creation flow received an atypical volume of batch requests containing inconsistent data and expired credentials. The validation service correctly rejected these requests due to invalid data. However, the circuit breaker mechanism on one of our internal services interpreted this concentrated volume of rejections as a downstream infrastructure failure and opened the circuit globally. As a result, process creation was temporarily blocked platform-wide, extending the impact beyond the original anomalous traffic. **Impact** The impact was strictly limited to the process creation flow. No data was lost or corrupted. * **Duration:** approximately 9 minutes \(from the first alert to full recovery\) * **Availability:** dropped to 95.8% * **Error volume:** approximately 5,100 error events logged * **Scope:** multiple users had their SLA/SLO targets affected during the period **Root Cause** The incident was caused by a combination of three architectural factors: 1. **Incorrect Error Classification:** The orchestration system did not differentiate between request validation errors \(HTTP 4xx\) and actual downstream service failures \(HTTP 5xx\). As a result, legitimate rejections due to invalid data were incorrectly counted as system unavailability. 2. **Lack of Traffic Isolation \(Multitenancy\):** The circuit breaker operated at a global level. The concentrated volume of errors from a single source was enough to open the circuit for the entire user base \(a "noisy neighbor" effect\). 3. **No Rate Limiting at the Edge:** There was no granular, per-origin rate limiter at the entry layer to contain the anomalous request volume before it impacted the internal ecosystem. **Resolution and Mitigation** The engineering team identified the pattern minutes after the first alert. Mitigation was carried out via a feature flag, disabling the circuit breaker's global behavior directly in production, with no need for a new deployment. Once disabled, the error volume normalized immediately and service availability was restored. **Lessons Learned and Next Steps** _What worked well:_ * **Effective Monitoring:** Multi-layer instrumentation \(application, edge, and infrastructure\) made it possible to correlate data and diagnose the issue quickly. * **Engineering Tooling:** The use of feature flags proved essential for record-time mitigation \(under 10 minutes\). As an action plan, we immediately adjusted the orchestration layer to disregard HTTP 4xx errors in the circuit breaker's metrics. In the medium term, we will refactor the protection mechanism to isolate point-in-time traffic spikes and prevent global impact, complementing this response with the already-completed update to our runbooks documenting this scenario. **Commitment to Transparency:** We apologize for the impact caused. This incident highlighted the need to accelerate our traffic isolation architecture, which is now being treated as a top priority by the engineering team. Unico Team.

Read the full incident report →

Started May 20, 2026, 02:27 AM UTC· resolved May 20, 2026, 02:37 AM UTC

1. identified May 20, 2026, 02:27 AM UTC

   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.

2. resolved May 20, 2026, 02:28 AM UTC

   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.

3. postmortem Jul 14, 2026, 01:28 PM UTC

   **Summary** On May 19, 2026, between 10:02 PM and 10:12 PM \(Brasília time\), multiple critical services experienced a simultaneous drop in availability for approximately 10 minutes, with the error rate peaking at 30% in a single minute and averaging 9% during the degradation window. The cause was the execution of a relational database maintenance window that had been manually rescheduled to that time, resulting in simultaneous restarts of production database instances. ‌ **Impact** Multiple services were affected simultaneously — including process creation flows, authentication, data capture, identity verification, and payments. Users received errors when attempting operations that depended on the restarted databases. The impact was widespread because multiple instances were restarted at the same time. ‌ **Root Cause** The root cause was identified as a database maintenance window that had been rescheduled to 10:00 PM on a Monday, replacing the standard configured window \(Friday/Saturday overnight\). The rescheduling used the SPECIFIC\_TIME type, which overrides the standard window only for that specific event. When the provider executed the maintenance at the scheduled time, all affected instances were restarted simultaneously, causing disruption to dependent services' connections for up to 15 minutes. The current process relies on manual evaluation and rescheduling, with no automated guardrails to prevent scheduling during high-traffic periods. ‌ **Resolution** All databases recovered automatically once the maintenance restarts were completed. No manual intervention was required to restore service. ‌ **Lessons Learned** The incident highlighted the need to strengthen controls over the database maintenance process: guardrails must be implemented to prevent rescheduling during high-traffic periods, the various maintenance window configurations currently in place across instances must be standardized, a staggered restart approach \(or transparent failover\) should be adopted to reduce the blast radius, and migration of the most critical instances to high-availability tiers with near-zero downtime should be prioritized.

Read the full incident report →

Started May 19, 2026, 02:20 PM UTC· resolved May 19, 2026, 03:00 PM UTC

1. identified May 19, 2026, 02:39 PM UTC

   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, o ambiente já está normalizado nesse momento, estamos iniciando um monitoramento para garantir a saúde do sistema. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. monitoring May 19, 2026, 02:40 PM UTC

   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. resolved May 19, 2026, 03:00 PM UTC

   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. postmortem Jul 07, 2026, 02:27 PM UTC

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

Read the full incident report →

Started May 19, 2026, 03:09 AM UTC· resolved May 19, 2026, 11:36 AM UTC

1. investigating May 19, 2026, 03:09 AM UTC

   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,

2. identified May 19, 2026, 03:14 AM UTC

   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

3. monitoring May 19, 2026, 03:26 AM UTC

   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!

4. resolved May 19, 2026, 11:36 AM UTC

   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

5. postmortem Jun 29, 2026, 01:35 PM UTC

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

Read the full incident report →

Started May 18, 2026, 11:37 AM UTC· resolved May 18, 2026, 02:35 PM UTC

1. investigating May 18, 2026, 11:37 AM UTC

   Prezado cliente, Identificamos uma instabilidade no acesso ao portal IDCloud, que pode 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.

2. investigating May 18, 2026, 12:27 PM UTC

   We are continuing to investigate this issue.

3. identified May 18, 2026, 12:33 PM UTC

   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

4. identified May 18, 2026, 01:08 PM UTC

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

5. monitoring May 18, 2026, 02:19 PM UTC

   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

6. resolved May 18, 2026, 02:35 PM UTC

   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.

7. postmortem Jun 29, 2026, 01:25 PM UTC

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

Read the full incident report →

Started May 15, 2026, 11:10 AM UTC· resolved May 15, 2026, 05:25 PM UTC

1. identified May 15, 2026, 12:26 PM UTC

   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

2. identified May 15, 2026, 01:00 PM UTC

   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

3. identified May 15, 2026, 03:50 PM UTC

   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

4. monitoring May 15, 2026, 05:15 PM UTC

   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

5. resolved May 15, 2026, 05:25 PM UTC

   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

6. postmortem Jun 26, 2026, 06:41 PM UTC

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

Read the full incident report →

Started May 14, 2026, 04:55 PM UTC· resolved May 14, 2026, 06:00 PM UTC

1. monitoring May 14, 2026, 06:51 PM UTC

   Prezado Cliente, Identificamos uma instabilidade em nossos serviços que pode ter impactado a disponibilidade de uma parcela mínima de nossas requisições para os fluxos do IDCloud (ByUnico e ByClient) e afetando também os produtos IDPay e IDSign. Informamos que as ações corretivas foram executadas com sucesso e o ambiente já apresenta estabilidade. Os picos de erros iniciaram por volta das 13:55BRT normalizando as 14:10BRT. Durante este intervalo, se não observou 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. Dentro de alguns dias disponibilizaremos um postmortem detalhando as causas e ações de melhoria contínua. Atenciosamente, Equipe Unico!

2. resolved May 14, 2026, 06:58 PM UTC

   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. Os serviços já podem ser utilizados normalmente. Pedimos desculpas pelo transtorno e em breve compartilharemos mais detalhes do ocorrido através de um postmortem. Atenciosamente, Equipe Unico

3. postmortem Jul 10, 2026, 01:46 PM UTC

   **Resumo** Em 14 de maio de 2026, entre 13h44 e 14h10 \(horário de Brasília\), a camada de borda da plataforma retornou erros HTTP 502 para uma parcela das requisições, com taxa de erro atingindo até 0,5% do total e aproximadamente 3% das requisições de criação de processos. A causa foi uma falha intermitente na infraestrutura de nuvem, especificamente na camada entre o balanceador de carga e o proxy de borda, que rejeitou requisições antes mesmo de chegarem aos serviços de backend. O incidente faz parte de uma série de instabilidades recorrentes na mesma camada, com ocorrências similares nos dois dias anteriores. **Impacto** Usuários de múltiplos fluxos — criação de processos, autenticação, pagamentos, assinatura digital e SDK — foram impactados de forma intermitente durante o período. As requisições eram rejeitadas na camada de borda antes de chegarem aos serviços de backend, que permaneceram saudáveis durante todo o incidente. O impacto foi generalizado para todos os clientes ativos na plataforma. **Causa Raiz** A causa raiz foi uma dependência externa: a infraestrutura de nuvem apresentou falha intermitente no caminho entre o balanceador de carga e o proxy de borda, retornando erros 502 com código interno de falha. Os serviços de backend estavam operando normalmente e não chegavam a receber as requisições afetadas. A causa exata dentro da infraestrutura do provedor não foi divulgada; um chamado de suporte prioritário estava aberto. O padrão de erro havia mudado em relação às ocorrências anteriores \(503 no dia anterior, 502 neste incidente\), indicando instabilidade recorrente não resolvida na mesma camada. **Resolução** A instabilidade cessou sem intervenção direta da equipe, uma vez que a causa estava na infraestrutura do provedor. A equipe atualizou o chamado de suporte aberto com evidências da nova ocorrência. O incidente foi encerrado às 14h10 após confirmação de estabilização. **Lições Aprendidas** * Os alertas de borda cobriam apenas um padrão específico de erro 503. Quando o padrão mudou para 502, a detecção ocorreu via queda no indicador de qualidade do serviço, com maior latência. A ampliação da cobertura de alertas para múltiplos padrões de erro de borda é uma melhoria prioritária. * A avaliação do escopo do impacto levou aproximadamente 40 minutos, em parte por sinais iniciais enganosos. Fortalecer a observabilidade na camada de borda — especialmente para erros originados na infraestrutura do provedor — aceleraria a identificação da causa raiz. * Esta foi pelo menos a terceira ocorrência de instabilidade na mesma camada em dias consecutivos. Instabilidades recorrentes de dependências externas demandam escalonamento proativo junto ao provedor e avaliação de alternativas arquiteturais para reduzir a exposição.

Read the full incident report →

Started May 12, 2026, 08:10 PM UTC· resolved May 12, 2026, 09:22 PM UTC

1. investigating May 12, 2026, 08:40 PM UTC

   Prezado Cliente, Nossa monitoração identificou um impacto no retorno de requisições para uma parcela de clientes com integração By Client. O impacto está gerando latência, seguida de timeout. Nosso time de tecnologia está mobilizado para identificar e resolver o problema. Se sua operação não percebeu degradação, seus fluxos não foram afetados neste incidente. Em breve retornaremos com novas atualizações.

2. identified May 12, 2026, 08:48 PM UTC

   Prezado Cliente, Identificamos a causa da instabilidade no retorno das requisições para uma parcela de clientes com integração By Client. Nosso time de tecnologia está atuando na resolução do incidente. Em breve retornamos com atualizações.

3. monitoring May 12, 2026, 09:08 PM UTC

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou uma instabilidade que afetou o tempo de resposta das requisições para uma parcela dos usuários da integração By Client. Ocorrência: Latência intermitente seguida de timeout. Período do impacto: Das 17:04 às 17:43 (Horário de Brasília). Status atual: Serviço normalizado após a aplicação de medidas de contingência. Caso sua operação não tenha apresentado degradação no intervalo mencionado, seus fluxos não foram afetados. Continuamos monitorando o ambiente e enviaremos o relatório detalhado em breve. Atenciosamente, Equipe Unico

4. resolved May 12, 2026, 09:22 PM UTC

   Comunicado de Incidente: Encerramento e Resolução Prezado Cliente, É prioridade da Unico manter a transparência e a confiança em nossas operações. Por isso, detalhamos abaixo o encerramento do incidente ocorrido hoje. 1. Resumo Executivo e Impacto Entre 17:04 e 17:43 (Horário de Brasília), identificamos uma instabilidade que afetou o tempo de resposta das requisições para uma parcela mínima de clientes que utilizam a integração By Client. O incidente manifestou-se por meio de latência intermitente, culminando em timeouts pontuais. Reforçamos que, caso sua operação não tenha registrado um aumento no volume de erros dentro deste intervalo específico, seus fluxos não sofreram qualquer impacto. Os serviços foram restabelecidos e operam com performance normalizada, incluindo o processamento de imagem e o motor de liveness. 2. Compromisso e Próximos Passos Nossa equipe permanece monitorando rigorosamente todos os indicadores para garantir a continuidade da operação. Como parte do nosso processo de melhoria contínua, um Postmortem detalhado está sendo elaborado e será compartilhado em breve, contendo as medidas preventivas que serão adotadas para evitar recorrências. Lamentamos sinceramente qualquer inconveniente causado e agradecemos pela parceria e compreensão. Atenciosamente, Equipe Unico

5. postmortem Jun 18, 2026, 01:28 PM UTC

   **Resumo** Em 12 de maio de 2026, às 17h05 \(horário de Brasília\), tivemos um problema de conexão com a atualização automática de um dos nossos certificados, causando falhas de conectividade para usuários de mais de 25 clientes. O incidente durou aproximadamente 36 minutos e foi mitigado às 17h40 com a antecipação de uma migração de infraestrutura já planejada. A causa foi um conflito silencioso entre dois sistemas de renovação automática de certificado, introduzido por uma mudança parcial de infraestrutura realizada dias antes. **Impacto** Usuários de mais de 25 clientes que utilizavam a integração via uma camada específica da plataforma enfrentaram falhas de conexão com erros de certificado inválido. Durante o período, os usuários não conseguiam estabelecer conexões seguras com o serviço. A página de status também foi afetada quando acessada via HTTPS, impedindo que os próprios usuários verificassem o estado do serviço durante o incidente. **Causa Raiz** A causa raiz foi um erro operacional em uma migração parcial de infraestrutura. Como parte da preparação para migrar um dos domínios de serviço para um novo provedor de rede, o registro DNS responsável pela validação automática do certificado SSL foi antecipadamente movido para o novo provedor. No entanto, o domínio de API principal ainda estava operando na infraestrutura anterior, aguardando uma janela de mudança agendada para 20 de maio. Essa inconsistência fez com que o processo de renovação automática do certificado falhasse silenciosamente — o sistema tentava validar o domínio por uma rota que não reconhecia mais. O conflito não foi detectado porque o registro DNS anterior não estava gerenciado como código de infraestrutura, tornando-o invisível durante as revisões de mudança. Quando o certificado atingiu sua data de expiração, ele não foi renovado e as conexões passaram a falhar imediatamente. Um incidente similar havia ocorrido dias antes, mas a relação entre os dois eventos não foi identificada a tempo. **Resolução** A equipe identificou o certificado expirado e a causa do conflito em poucos minutos. Como a renovação automática não era mais viável no curto prazo, a decisão foi antecipar a migração do domínio para o novo provedor de rede — prevista para 20 de maio. A mudança foi executada às 17h40, restaurando o serviço. Outros domínios no mesmo estado de migração parcial foram identificados para tratamento preventivo imediato. **Lições Aprendidas** * Mudanças em registros DNS de validação de certificado no nível wildcard têm escopo amplo: afetam todos os subdomínios cobertos, não apenas o que está sendo migrado. Migrações parciais que alteram esses registros antecipadamente criam estados inconsistentes que podem falhar silenciosamente até a próxima renovação do certificado. * A ausência de monitoramento proativo de expiração de certificados foi o fator que permitiu que o problema só fosse detectado quando as conexões já estavam falhando. Alertas com antecedência de 14 a 30 dias antes da expiração são essenciais para evitar esse tipo de incidente. * Registros DNS e de validação de certificados não gerenciados como código de infraestrutura são pontos cegos: não aparecem em revisões de mudança e podem entrar em conflito com novas configurações sem que ninguém perceba. A cobertura completa desses registros em infraestrutura como código é uma melhoria estrutural prioritária. * A página de status compartilhava a mesma dependência de certificado que os serviços afetados, ficando inacessível via HTTPS durante o incidente. A página de status deve ter infraestrutura independente dos serviços que monitora para permanecer disponível justamente quando mais é necessária.

Read the full incident report →

Started May 12, 2026, 12:55 PM UTC· resolved May 12, 2026, 01:57 PM UTC

1. investigating May 12, 2026, 01:04 PM UTC

   Prezado Cliente, Estamos analisando um impacto na capacidade de Token Biométrico, podendo gerar impacto nos retornos das requisições 1:1 e 1:N. Nosso time de tecnologia está analisando o ambiente. Em breve retornaremos com novas atualizações.

2. identified May 12, 2026, 01:12 PM UTC

   Prezado cliente, Nossa equipe de tecnologia identificou a possível causa da instabilidade na capacidade do Token Biométrico, gerando impacto nos retornos das requisições do fluxo 1:1 e 1:N. Em breve retornaremos com atualizações sobre as ações corretivas.

3. monitoring May 12, 2026, 01:41 PM UTC

   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!

4. resolved May 12, 2026, 01:57 PM UTC

   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. Causa Raiz e Resolução: A instabilidade foi desencadeada por uma atualização planejada de infraestrutura, que visava expandir as capacidades multirregião de um dos nossos sistemas centrais. Essa alteração gerou uma latência imprevista na comunicação entre os serviços internos de orquestração, resultando em timeouts em cascata. Para mitigar o problema, nossa equipe de engenharia agiu rapidamente e executou a reversão (rollback) completa da atualização. O procedimento foi concluído com sucesso às 10:38 (BRT), estabilizando as operações e normalizando integralmente o ambiente sem novos registros de erros desde então. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

5. postmortem May 28, 2026, 02:15 PM UTC

   **Resumo Executivo** Em 11 de maio de 2026, nossa plataforma apresentou instabilidade parcial nos fluxos de autenticação e captura de dados que dependem de um dos nossos motores de _liveness_ \(prova de vida\). O incidente foi provocado pela expiração das credenciais de acesso ao componente desse fornecedor. A situação foi mitigada e a operação normalizada após a atualização imediata das credenciais na nossa infraestrutura. **Impacto** Durante a janela de instabilidade, uma parcela mínima de usuários não conseguiram concluir jornadas que exigiam a validação pelo motor de _liveness_ afetado, resultando em falhas nas tentativas de captura. Clientes configurados para utilizar com múltiplos motores de _liveness_ na Unico não sofreram impacto direto nas capturas. **Causa Raiz** A instabilidade foi causada por uma falha nas chaves de integração de um motor de _liveness específico_. **Resolução e Mitigação** A partir do diagnóstico das mensagens de erro na integração com o componente, nossa equipe de engenharia realizou prontamente a rotação e atualização de chaves de acesso que causavam o problema. * Em seguida, todos os serviços de orquestração envolvidos foram reiniciados para reconhecer a atualização. * O restabelecimento total dos fluxos de autenticação e a recuperação dos indicadores de saúde do sistema foram confirmados às 22:25, momento em que o serviço retornou à sua operação padrão. **Lições Aprendidas e Prevenção** Para fortalecer a resiliência do sistema, automatizaremos o monitoramento preventivo deste fluxo. Além disso, os mecanismos de proteção de rede serão refinados para atuar estritamente em falhas críticas de conectividade, isolando o impacto de dependências e preservando a estabilidade dos serviços saudáveis. Seguimos comprometidos com a disponibilidade dos serviços e focamos em melhoria contínua, mitigando impactos aos nossos clientes. Equipe Unico.

Read the full incident report →

Started May 12, 2026, 12:11 AM UTC· resolved May 12, 2026, 02:09 AM UTC

1. investigating May 12, 2026, 12:51 AM UTC

   Nossa monitoração identificou um impacto parcial em um fornecedor externo de liveness, podendo gerar impacto nos retornos das capacidades do ID Cloud e ID Pay

2. identified May 12, 2026, 01:50 AM UTC

   Identificamos a causa da instabilidade no serviço de Liveness integrada às capacidades da Unico. Nosso time de tecnologia está atuando para reestabelecer o ambiente. Em breve retornamos com atualizações.

3. monitoring May 12, 2026, 01:53 AM UTC

   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!

4. resolved May 12, 2026, 02:09 AM UTC

   Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. O impacto ocorreu entre às 21:11 e 22:25. 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.

5. postmortem Jun 09, 2026, 07:10 PM UTC

   **Resumo** Em 11 de maio de 2026, a partir das 21h32 \(horário de Brasília\), os fluxos de autenticação e captura de dados que dependem de um componente de validação de vivacidade de terceiros ficaram indisponíveis por aproximadamente 74 minutos, encerrando às 22h25. O incidente foi causado pela expiração de determinados componentes do serviço, resultando em falhas de autenticação e na indisponibilidade de múltiplos serviços. Aproximadamente 67.500 tentativas de captura de dados foram travadas durante o período. **Impacto** Usuários que utilizavam fluxos de autenticação dependentes do componente de validação de vivacidade afetado não conseguiram concluir suas jornadas. O impacto se estendeu além dos fluxos diretamente dependentes: o alto volume de erros ativou mecanismos de proteção da malha de serviço \(circuit breaker\), que ejetaram componentes de orquestração em uma das regiões de infraestrutura, deslocando o tráfego de forma instável para outra região e causando degradação adicional em serviços que estavam saudáveis. No total, mais de 40 alertas de indicadores de qualidade do serviço foram disparados. Clientes que utilizavam outro motor de validação de vivacidade não foram afetados. **Causa Raiz** A causa raiz foi devido a um erro em determinado componente de atualização de credenciais: O processo de renovação dependia de um passo manual — o agendamento de uma chamada de renovação 10 dias antes da expiração — que não foi executado na última rotação. Adicionalmente, o fornecedor havia reduzido o ciclo de validade das credenciais de 3 meses para 1 mês sem que os controles internos fossem ajustados, fazendo com que a expiração ocorresse antes do prazo esperado pela equipe. Não havia monitoramento automatizado para detectar a aproximação da expiração. **Resolução** Após identificar a mensagem de erro do SDK indicando a expiração do componente, a equipe realizou a rotação e reiniciou todos os serviços relevantes. Uma autenticação bem-sucedida foi confirmada após a atualização, e a recuperação dos indicadores de saúde foi observada nos painéis de monitoramento. O serviço voltou ao normal às 22h25. **Lições Aprendidas** * O processo de gestão de credenciais de SDKs externos dependia exclusivamente de um passo manual sujeito a falha humana, sem nenhum mecanismo automatizado de backup. A criação de um agente de monitoramento de expiração de credenciais externas é a melhoria mais crítica identificada neste incidente. * Mudanças nos ciclos de validade impostas por fornecedores externos precisam ser capturadas e refletidas nos controles internos imediatamente, para evitar que expectativas desatualizadas levem a renovações fora do prazo. * O comportamento do circuit breaker da malha de serviço amplificou o impacto: ao ser ativado por erros de conexão com uma dependência específica, ele afetou serviços que estavam completamente saudáveis. Restringir o circuit breaker para atuar apenas em falhas de conexão — em vez de todos os erros 5xx — reduziria significativamente o raio de impacto em incidentes semelhantes. * Este incidente reforça a necessidade de uma auditoria ampla sobre outras credenciais, tokens e certificados externos que possam estar sem monitoramento automatizado de expiração.

Read the full incident report →

Started May 11, 2026, 04:30 PM UTC· resolved May 11, 2026, 05:51 PM UTC

1. identified May 11, 2026, 04:52 PM UTC

   Prezado Cliente, Detectamos um impacto nas requisições com o fluxo do IDTrust, causando instabilidade aos clientes 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. monitoring May 11, 2026, 05:37 PM UTC

   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. resolved May 11, 2026, 05:51 PM UTC

   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. postmortem May 28, 2026, 02:40 PM UTC

   **Resumo Executivo** Em 11 de maio de 2026, nosso serviço de biometria apresentou uma instabilidade parcial que resultou em uma queda temporária no indicador de disponibilidade, com duração aproximada de 1 hora e 8 minutos. O incidente foi causado pela saturação de recursos de processamento que não se comportou adequadamente. A operação foi totalmente normalizada após a intervenção da nossa equipe de engenharia. **Impacto** Usuários finais que tentaram realizar jornadas de validação por biometria facial durante o período afetado enfrentaram lentidão e falhas pontuais. As requisições demoravam mais que o projetado sistemicamente e algumas eram canceladas por tempo limite excedido \(_timeout_\), devolvendo erros para as aplicações clientes. **Causa Raiz** A instabilidade ocorreu devido à uma falha de infraestrutura na distribuição do processamento de dados combinada com um aumento no consumo de processamento por requisição não mapeado. **Resolução e Mitigação** * Assim que a anomalia no indicador de disponibilidade foi detectada, nossa equipe de resposta a incidentes identificou a origem do problema e interrompeu rotinas manuais, liberando o tráfego, retomando o indicador de disponibilidade do serviço. **Lições Aprendidas e Ações Preventivas** Para mitigar falhas, o processo será aprimorado com a distribuição obrigatória de carga, testes de desempenho ampliados sob estresse paralelo e novos alertas proativos de observabilidade para diagnóstico rápido e _timeouts_. Mantemos nosso compromisso com a disponibilidade máxima de nossas soluções. Equipe Unico.

Read the full incident report →