Unico incident
Instabilidade no fluxo de onboarding - By Unico e IDPay
Unico experienced a major incident on June 23, 2026 affecting API and Messaging System, lasting 1h 17m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating Jun 23, 2026, 01:24 AM UTC
Prezado Cliente, Nossa monitoração proativa detectou um comportamento irregular no fluxo de onboarding (ByUnico e IDpay). 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.
- identified Jun 23, 2026, 01:39 AM UTC
Prezado Cliente, Nossa equipe ainda está investigando a causa raiz do problema. Em breve traremos mais atualizações. Agradecemos a compreensão.
- identified Jun 23, 2026, 01:53 AM UTC
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.
- monitoring Jun 23, 2026, 02:18 AM UTC
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!
- resolved Jun 23, 2026, 02:41 AM UTC
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!
- postmortem Jul 14, 2026, 01:58 PM UTC
**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.