Is Unico down?

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.

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.

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