Unico outage history

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

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

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

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

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.

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.

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.

**Summary** 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. **Impact** 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. **Root Cause** 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. **Resolution** 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. **Lessons Learned** 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.

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,

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,

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,

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,

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

**Summary** On July 29, 2026, between 8:32 AM and 10:05 AM \(Brasília time\), the webhook delivery service was degraded for approximately 1 hour and 33 minutes. The incident was caused by a planned infrastructure migration that created a transient incompatibility state: after internal routes were switched to the new cluster, the webhook service began generating authentication tokens from the new cluster, but deliveries were still being directed to the old cluster — which rejected the tokens with an authorization error. Lost events were reprocessed on demand. **Impact** Multiple products were affected simultaneously — including authentication, payments, and onboarding flows. Users of clients that relied exclusively on webhook notifications to continue their business flows experienced operational interruptions during the period. Clients that had implemented active polling as a fallback mechanism experienced reduced impact. **Root Cause** The root cause was identified in the migration planning: the procedure did not map the chained dependency of the webhook flow — where the internal route creates an asynchronous task that, in turn, calls the public route for delivery. By migrating the internal routes and the public routes in separate steps, an incompatibility window was created where tokens generated by the new cluster were rejected by the old cluster's authorization policy, which specifically validated the previous service account identifier. This scenario was not identified during the change's risk assessment, and none of the existing service quality indicators covered the asynchronous delivery layer where the failure materialized. **Resolution** The team identified the token incompatibility as the source of the failures and completed the migration of the public routes to the new cluster, eliminating the divergence. From that point on, the pending deliveries in the queue began processing normally. The impact ceased at 10:05 AM, and traffic on the old cluster reached zero at 10:32 AM. **Lessons Learned** The incident showed that migrations involving chained asynchronous delivery flows require all routes participating in the chain — internal and public — to be migrated in a coordinated manner, without incompatibility windows between clusters. The gradual approach used, while suitable for most migrations, created a prolonged failure period here that could have been avoided with an atomic transition or a much shorter transition window. Additionally, the lack of observability at the asynchronous delivery layer was the reason the incident was not detected internally — existing indicators measured only event acceptance, not actual delivery. Creating dedicated alerts for failures and backlog at this layer is the most urgent monitoring improvement identified.

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.

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.

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.

**Summary** On July 24, 2026, between 6:05 PM and 6:29 PM \(Brasília time\), the webhook creation and delivery service was unavailable for approximately 24 minutes. The incident was caused by the loss of access to an infrastructure service account during a resource decommissioning process linked to a cluster migration carried out days earlier. The affected account was shared by multiple services without this dependency being documented, causing the webhook service to lose its authentication capability and stop creating and delivering events. **Impact** Webhook event creation and delivery was interrupted during the period, affecting 18 client users with more than 1,550 errors recorded. The impact cascaded to other services that depended on the same authentication flow, causing simultaneous degradation across different platform capabilities. **Root Cause** The root cause was identified in the service dependency configuration. This cross-service dependency was neither documented nor visible in any dependency mapping. When the decommissioning process removed the account as part of the original service's resource cleanup, there was no automated validation to check whether the account was still being used by other active services. The absence of this safeguard kept the dependency hidden until its removal caused widespread authentication failures. **Resolution** The team quickly identified the unstable service account as the source of the authentication failures. The account was manually adjusted and applied to the cluster, restoring the service at 6:29 PM. The total impact duration was approximately 24 minutes. **Lessons Learned** The incident exposed the risks of legacy configurations that create hidden dependencies between services: a single resource change during planned maintenance was enough to disrupt multiple services simultaneously. The infrastructure resource decommissioning process must include automated dependency validation before any change.

Dear customer, We are investigating an instability in the IDCloud functionalities that affects the authentication flows in the process journey, specifically impacting the Web Journey (formerly ByUnico). Our engineering team is mobilized to resolve the issue as soon as possible. We will provide further updates shortly.

Dear Customer, 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.

Executive Summary and Impact Starting at approximately 12:44 PM (Brasília time) on July 21, 2026, a portion of users in the reduced onboarding journey experienced slower loading of the initial screens in the flow. The impact was observed across all environments where this journey is used, affecting perceived speed and, to a lesser extent, users' ability to complete the process during this period. Root Cause and Resolution The investigation is ongoing to confirm the definitive root cause of the incident. There was no impact on servers, network, or infrastructure — the issue was confirmed to be isolated to the on-screen experience on the user's device. As a containment measure, the responsible team applied a preventive adjustment at 1:39 PM (BRT), and loading times returned to normal within a few minutes. The analysis to validate and confirm the root cause is still being conducted by the technical team. Commitment and Next Steps As part of the continuous improvement of incident response processes, the team commits to enhancing the automatic escalation flow for responsible teams, making activation even more direct and effective from the moment an incident is opened. Additionally, loading-speed monitoring will be strengthened during the rollout of new changes to this journey, with the goal of identifying and correcting potential regressions even faster, minimizing impact to users in similar situations going forward.

**Summary** On July 21, 2026, between 12:44 PM and 1:43 PM \(Brasília time\), page load performance indicators for the reduced journey degraded severely, with average load time jumping from ~4.8s to ~8.9s and the p95 reaching 31.5 seconds. The incident was caused by rate limiting applied by the cloud infrastructure on connections originating from the provider, which prevented frontend assets from loading. **Impact** Users from 32 clients experienced extremely slow page loads or complete loading failures, with approximately 94 journey errors recorded. "Initialization Timeout" errors — triggered when the application fails to mount within 30 seconds — reached about 23 thousand occurrences during the period. **Root Cause** The root cause was identified in the infrastructure's network layer: the CDN provider consolidates traffic through a limited set of outbound IP addresses. A spike in new TCP connections and TLS handshakes originating from these IPs triggered the cloud infrastructure's automatic network-layer defense mechanisms, which began rate-limiting connections even before HTTP processing. Because these failures occurred at the network layer — before HTTP processing — they did not appear in standard request logs, making the problem invisible to conventional monitoring and significantly complicating diagnosis. **Resolution** The impact ceased with the natural recovery of the rate limiting applied by the cloud infrastructure. The deactivation of a component, initially flagged as a possible cause, coincided temporally with the recovery but was later confirmed to be unrelated to the incident. Configuration fixes — enabling HTTP Keep-Alive with an extended timeout and adding an allow rule for CDN IPs at the edge protection layer — were identified as follow-up items by the support teams of the providers involved. **Lessons Learned** The incident highlighted that failures at the network layer between the CDN and cloud infrastructure are invisible to standard application monitoring, creating a significant blind spot. As follow-up items, the team identified the need to implement the configuration fixes recommended by the providers and to expand observability at the asset delivery layer to proactively detect this type of degradation.

Dear customer, We are investigating an instability in our IDCloud capabilities, affecting the process creation and process details flows. Our engineering team is mobilized to resolve the issue as soon as possible. We will provide further updates shortly.

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

Dear Customer, 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.

Executive Summary and Impact On July 21, 2026, at around 11:17 AM BRT, a drop in availability was detected in the IDCloud create-process and process-query flows. During the impact window, a portion of customers experienced elevated latency and failures (timeouts) in these operations, which propagated through the chain of dependent services. The effective impact was concentrated in a window of approximately 23 minutes. At peak, error and latency indicators were above normal operating levels. Root Cause and Resolution The investigation pointed to the degradation of a read database (replica) supporting these capabilities as the origin. This database began to show increased load and query execution time, with internal contention that stalled processing and backed up read requests. As a result, the services above it started accumulating timeouts and triggering protection mechanisms (circuit breakers), producing the cascading effect experienced by customers. Commitment and Next Steps Unico is handling this incident with a detailed postmortem, already being drafted, and will hold a post-incident review (PiR) meeting to consolidate preventive actions. Among the follow-ups already raised during the response are the preparation of diagnostic routines and queries to speed up the identification of contention in this database layer, and improved observability over the databases involved. The detailed preventive actions will be shared in the postmortem. We reaffirm our commitment to the stability and reliability of the platform and apologize for the inconvenience caused during the period of instability. Unico Team.

**Summary** On July 21, 2026, between 11:41 and 11:43 AM \(Brasília time\), the process creation flow became unavailable, with the main service error rate reaching 42% and p99 latency at 15.75 seconds. The incident was caused by saturation on the biometry database read replica: the database memory pool was no longer able to serve the most frequently accessed dataset, causing normally fast queries to fall back to disk reads, creating a self-reinforcing spiral of accumulated sessions and increasing latency. **Impact** Users of the process creation, authentication, and payments flows across multiple clients received errors and timeouts during the period. The primary database remained intact throughout the incident — the failure was isolated to the read replica. **Root Cause** The root cause was saturation: queries used in the authentication flow were performing extensive scans on critical tables due to missing indexes. Under normal conditions, this behavior was tolerated by the database infrastructure. When memory capacity reached its limit and could no longer keep the most accessed data in cache, each read began fetching data from disk, making the cost of each query exponentially higher. This abrupt collapse effect — where gradual degradation gives way to a widespread failure — became self-reinforcing as sessions accumulated waiting for responses and internal database resource contention increased. Additionally, all read traffic for the critical flow was concentrated on a single replica, with no distribution or alternative route, eliminating any resilience to this type of degradation. **Resolution** The database recovered naturally as the accumulated sessions drained, requiring no manual intervention. The team escalated to the database team and monitored service stabilization. The incident was closed after confirmation that normal operation had been restored. **Lessons Learned** The incident revealed structural gaps in the database layer: missing indexes on critical queries and concentration of all read traffic on a single replica with no alternative route. As follow-ups, the team prioritized creating the missing indexes, distributing read traffic across replicas, and building diagnostic runbooks to accelerate response in future incidents of a similar nature.

Dear Customer, We have identified an instability in some of our IDCloud capabilities, affecting the GetSelfie, process creation, and process details flows for the Web Journey (formerly ByUnico). The API Journey (ByClient) flows were not affected. Our engineering team is mobilized to resolve the issue as soon as possible. We will follow up shortly with further updates.

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

Dear Customer, 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.

Executive Summary and Impact We identified an instability affecting the process capture and visualization flows, as well as authentication, for the Web Journey, with impact between 09:07 and 09:21 (BRT). The impact reached a portion of clients using this flow; the API Journey was not affected. Root Cause and Resolution The root cause is linked to a configuration change applied in production, which caused increased load on an internal database component. This increased load raised latency and errors in an integration layer, which in turn triggered a protective mechanism and temporarily interrupted the Web Journey flows. The engineering team rolled back the configuration change to mitigate the issue, and the situation normalized shortly after. Commitment and Next Steps The engineering team continues to monitor the environment following the rollback of the changes made. A detailed postmortem will be shared by our team in the coming days. We apologize for the inconvenience. Unico Team!

**Summary** On July 20, 2026, between 9:07 AM and 9:21 AM \(Brasília time\), the selfie capture and authentication flows were unavailable for approximately 14 minutes. The incident was caused by a query without an adequate index running as part of the database migration flow, causing database CPU to spike to 53%, dependent service latency to jump 78 times above normal, and the circuit breaker mechanism to fully block calls to the affected service. The causing behavior was reverted and the service recovered in approximately 1 minute. **Impact** Users of the selfie, authentication, and web-based proof-of-life flows received open-circuit errors during the period, with 743 and 125 requests blocked respectively in the most affected flows. The service returned to normal at 9:21 AM after the causing behavior was reverted **Root Cause** The root cause was identified in the database migration flow: a query introduced as part of the migration lacked the index needed to run efficiently on the new database. When the new behavior was activated in production, the query began performing full scans per tenant, with the number of rows read jumping from ~5 million to ~25 million per execution, saturating the database CPU and causing response latencies of up to 10 seconds. **Resolution** The team identified the database CPU spike as the source of the problem and correlated it with the recently introduced behavior change approximately 7 minutes after the first alert. The change was reverted at 9:20 AM, and the service recovered immediately. **Lessons Learned** The incident showed that volume differences between validation and production environments can mask performance issues that only manifest at real-world scale. Silent error handling in the application worsened the situation by making the degradation invisible to monitoring. As follow-up actions, the team prioritized creating the missing index and removing the silent error suppression pattern.

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.

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.

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.

**Summary** On July 16, 2026, between 10:12 AM and 11:10 AM \(Brasília time\), the messaging and authentication service was degraded for approximately 58 minutes. The cause was disk saturation on one of the nodes in the message queue cluster, which, upon reaching the configured limit, automatically blocked all publishers, causing a backlog of up to 33 thousand messages in the queue. The impact affected the delivery of authentication links via SMS and email, as well as the end-user authentication flow on the Unico People admission portal. **Impact** Users waiting for authentication links via SMS or email did not receive them during the period. End users of a people management product attempting to authenticate on the admission portal were also unable to access the service. The impact was contained after the cluster's disk was expanded. **Root Cause** The root cause was identified in the message processing flow: excessively large payloads — generated by an auditing component that included unnecessary data — exceeded the size limit accepted by the message queue cluster. Since they were deterministically rejected on every attempt, these messages were routed to dead-letter queues after exhausting all retries. These queues had no expiration or automatic cleanup policy, causing messages to accumulate indefinitely and progressively consume the cluster's disk space. **Resolution** The cluster's disk was expanded to 500 GB per node, which immediately normalized the queues and cluster metrics. The service returned to normal at 11:10 AM. The structural root cause — the indefinite accumulation in the dead-letter queues — remains as a follow-up item to be addressed. **Lessons Learned** The incident reinforces that addressing only the symptom \(disk saturation\) without investigating the root cause of the accumulation guarantees recurrence of the problem. The absence of a lifecycle policy \(TTL/expiration\) for dead-letter queues and the lack of payload size validation prior to publishing are the two central structural gaps to be corrected. Additionally, the alert that flagged the issue was classified as low priority, which caused a delay of approximately 38 minutes between the alert being triggered and the formal opening of the incident — an unacceptable interval for a critical service degradation.

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

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

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

# Postmortem: Authentication Flow Instability **Incident date:** July 13, 2026 **Impact duration:** ~44 minutes ## Summary On July 13, 2026, we identified an availability degradation in the platform's authentication flows. The incident was caused by an incompatibility introduced during a rolling deployment of an internal component responsible for validating security tokens. The cause was diagnosed by our operations teams, and rolling back the update restored system stability within minutes. ## Impact The degradation lasted approximately 44 minutes and simultaneously affected multiple authentication flows on the platform, resulting in an error rate of approximately 0.9% in customer-facing services. During this period, some end users experienced instability and saw generic error messages \(HTTP 500\) when attempting to authenticate. Although the event lasted 44 minutes, it fluctuated between increased latency and unavailability. ## Root Cause The failure was caused by a software defect introduced in an update to the security token validation component, resulting in incompatibility between instances running different versions. This incompatibility was not detected in test environments, since it required the simultaneous, parallel execution of different versions. Additionally, the internal endpoint returned an HTTP success response even when validation failed, which prevented automated deployment monitoring systems from detecting the issue and automatically halting the rollout. ## Resolution Once the cause was identified, the on-call team executed a rollback of the affected component, immediately restoring availability of the authentication flows. The incident was detected by automated SLO alerts within minutes of the degradation starting, and escalation enabled full diagnosis and mitigation of the incident. ## Lessons Learned We will improve version-compatibility validation in rolling deployments, adjust the HTTP response behavior of internal endpoints to trigger automatic rollback of failing deployments, and standardize error handling to prevent failures from being masked before reaching the customer. ## Commitment to Continuous Improvement Incidents like this one reinforce our commitment to continuously improving platform reliability. We treat every incident as a learning opportunity, reviewing our processes, strengthening detection and prevention mechanisms, and continuously investing in more robust engineering practices. Our goal is to keep raising the bar on availability and transparency for all of our customers. Unico Team.

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

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

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

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

**Summary** On July 10, 2026, between 1:21 PM and 2:09 PM \(Brasília time\), the error rate in the process creation flow peaked at approximately 11% for about 9 minutes, with continued availability degradation until 2:09 PM. The incident was caused by an instability in the infrastructure configuration management component, which prevented the biometrics service pods from initializing correctly. The impact was amplified by a pre-existing memory consumption behavior \(which increased the frequency of pod restarts\) and by a traffic spike that triggered the creation of new instances — all of which were unable to initialize during the configuration component's instability window. ‌ **Impact** Multiple flows were affected simultaneously — including process creation, authentication, biometrics, payments, and internal operations — with errors propagating across all services dependent on the biometrics engine. At its peak, the error rate reached 11%. The number of available biometrics service pods dropped to near zero in both production clusters during the most critical window of the incident. ‌ **Root Cause** The root cause was related to an optimization opportunity in the biometrics service's startup logic: the application refused to come up if the infrastructure configuration management component returned a failure during boot, even when cached data was available for use as a fallback. This logic treated a transient communication outage the same way as a permanent configuration error, rendering the fallback cache unusable at exactly the moment it was needed most. When the configuration component became unstable, every pod attempting to restart — whether due to memory pressure or autoscaling — got stuck in a failure loop, unable to complete the initialization process. ‌ **Resolution** The team contained the initial impact by isolating traffic from one of the affected components, which stopped the error spike within approximately 9 minutes. Stabilization of the configuration management component followed, allowing pods to come back up normally. An emergency fix was prepared and deployed the same day, removing the restrictive validation that blocked startup — ensuring the fallback cache is used transparently in similar situations going forward. **Lessons Learned** The incident revealed that the service's resilience mechanism — the fallback cache — existed in the architecture but was neutralized by the startup logic, which prioritized strict data validation over environment availability. Startup paths for critical services must be designed to degrade gracefully when supporting infrastructure components are unstable, ensuring operational continuity. **Commitment to Stability and Continuous Improvement** We will continue to invest heavily in the robustness of our infrastructure to ensure our services consistently operate at the highest levels of efficiency, security, and reliability. Unico Team.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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