Instability affecting ID CLOUD capabilities

Update timeline

1. investigating Jul 10, 2026, 04:43 PM UTC

   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.

2. identified Jul 10, 2026, 05:12 PM UTC

   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.

3. monitoring Jul 10, 2026, 05:25 PM UTC

   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.

4. resolved Jul 10, 2026, 05:57 PM UTC

   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

5. postmortem Jul 14, 2026, 02:08 PM UTC

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