Unico incident
Instability affecting ID CLOUD capabilities
Unico experienced a notice incident on August 10, 2026, lasting –. The incident has been resolved; the full update timeline is below.
Update timeline
- 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.
- 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.
- 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.
- 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.