Is Unico down?

Bom dia! Identificamos uma possível instabilidade no acesso ao Unico People. Nossos sistemas seguem funcionando normalmente, mas identificamos um problema externo em um provedor global de segurança na internet (Cloudflare). Esse cenário tem bloqueado temporariamente a tela de login para colaboradores conectados à rede corporativa de algumas empresas — por isso, o impacto não afeta todos os usuários. Nossa equipe está acompanhando com a Cloudflare a resolução desse problema e aguardando uma posição oficial do provedor. Acompanhamento do incidente na Cloudflare: https://www.cloudflarestatus.com/incidents/dk2obcyw2aew Seguimos monitorando e avisaremos assim que tivermos novidades sobre a normalização. Qualquer dúvida, estamos à disposição! Atenciosamente

Informamos que a instabilidade no acesso ao Unico People foi resolvida. O provedor externo (Cloudflare) concluiu a aplicação da correção e confirmou que a falha que afetava o login em algumas redes corporativas foi solucionada. O acesso à plataforma já se encontra restabelecido e operando normalmente. Agradecemos pela paciência e compreensão durante o ocorrido. Permanecemos à disposição! Atenciosamente,

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

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

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

**Summary** In the early hours of August 29–30, 2026, between 23:00 and 23:47 \(Brasília time\), process creation on the platform became unavailable, resulting in 503 errors for all users attempting to access the service. The incident lasted approximately 47 minutes and affected 91 user groups, with a direct impact on more than 63,000 requests. **Impact** The success rate for the process creation flow dropped to 67.86% against a 99% availability target. Of the 196,884 requests during the period, 63,273 resulted in failure. The highest volume of errors was recorded among users of sports betting platforms, which operate with high traffic volumes especially during live matches. In addition, other user groups — including financial and healthcare services — were affected to a lesser extent. **Root Cause** The incident was caused by a design flaw in the interaction between two automated database maintenance processes, compounded by high traffic volume at the time of the event. The database was running a mandatory internal maintenance operation on the main process table. This type of maintenance is non-interruptible and holds an exclusive lock on the table. At the same time, a scheduled partition creation job on another table — which has a foreign key relationship with the process table — attempted to acquire a lock on the same main table. Because the database uses a lock queue, the partition job waited indefinitely \(with no timeout configured\), causing all subsequent write operations to also queue up. This accumulation exhausted the service's available connection limit, causing new connections to be rejected. Since application pods perform a database connectivity check on startup and fail immediately when unable to connect — with no retry mechanism — 99 out of 100 pods entered a continuous restart loop, rendering the service completely unavailable at the edge layer. **Resolution** The mitigation was precise and surgical: only the blocked partition job session was terminated. Immediately after, the accumulated connections were released — dropping from ~1,500 to 19 within seconds — the pods returned to normal operation, and the availability indicator reached 100% at 23:48. **Lessons Learned** * The scheduled maintenance job had no lock acquisition timeout configured. A timeout of just a few seconds would have been enough for the job to fail gracefully and be rescheduled in the next cycle, preventing the cascading failure. * The foreign key relationship between the partition table and the main process table was identified as the architectural link that connected a low-impact maintenance job to an extremely high-write table. This relationship was removed as part of the fixes applied after the incident.

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.

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.

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.

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.

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.