Instabilidade parcial na criação de processos - IDCloud

Update timeline

1. identified May 20, 2026, 02:27 AM UTC

   Prezado Cliente, Identificamos uma instabilidade na funcionalidade de criação de processos e fluxos de autenticação. Informamos que o impacto ocorreu pra uma parcela minima de clientes, de forma intermitente, por um periodo de aproximadamente 10 minutos.. Caso você não tenha notado elevação no número de erros durante este intervalo, sua operação consequentemente não foi afetada. Equipe Unico.

2. resolved May 20, 2026, 02:28 AM UTC

   Informamos que o incidente iniciado às 22h02, que causou instabilidade nas requisições de criação de processos, foi normalizado às 22h12. Durante esse período houve uma degradação temporária de disponibilidade, sem perda de dados. O impacto ocorreu apenas para uma parcela reduzida de clientes. Nossa equipe atuou no acompanhamento e estabilização do ambiente, e os serviços já operam normalmente. Um postmortem detalhado será compartilhado posteriormente com mais informações sobre o ocorrido e os próximos passos. Pedimos desculpas pelos transtornos e agradecemos a compreensão. Equipe Unico.

3. postmortem Jul 14, 2026, 01:28 PM UTC

   **Summary** On May 19, 2026, between 10:02 PM and 10:12 PM \(Brasília time\), multiple critical services experienced a simultaneous drop in availability for approximately 10 minutes, with the error rate peaking at 30% in a single minute and averaging 9% during the degradation window. The cause was the execution of a relational database maintenance window that had been manually rescheduled to that time, resulting in simultaneous restarts of production database instances. ‌ **Impact** Multiple services were affected simultaneously — including process creation flows, authentication, data capture, identity verification, and payments. Users received errors when attempting operations that depended on the restarted databases. The impact was widespread because multiple instances were restarted at the same time. ‌ **Root Cause** The root cause was identified as a database maintenance window that had been rescheduled to 10:00 PM on a Monday, replacing the standard configured window \(Friday/Saturday overnight\). The rescheduling used the SPECIFIC\_TIME type, which overrides the standard window only for that specific event. When the provider executed the maintenance at the scheduled time, all affected instances were restarted simultaneously, causing disruption to dependent services' connections for up to 15 minutes. The current process relies on manual evaluation and rescheduling, with no automated guardrails to prevent scheduling during high-traffic periods. ‌ **Resolution** All databases recovered automatically once the maintenance restarts were completed. No manual intervention was required to restore service. ‌ **Lessons Learned** The incident highlighted the need to strengthen controls over the database maintenance process: guardrails must be implemented to prevent rescheduling during high-traffic periods, the various maintenance window configurations currently in place across instances must be standardized, a staggered restart approach \(or transparent failover\) should be adopted to reduce the blast radius, and migration of the most critical instances to high-availability tiers with near-zero downtime should be prioritized.