Instabilidade no acesso aos Portais Unico

Update timeline

1. investigating May 18, 2026, 11:37 AM UTC

   Prezado cliente, Identificamos uma instabilidade no acesso ao portal IDCloud, que pode se manifestar como um timeout ou em um erro ao fazer o acesso. Nosso time de engenharia está atuando na normalização do serviço.

2. investigating May 18, 2026, 12:27 PM UTC

   We are continuing to investigate this issue.

3. identified May 18, 2026, 12:33 PM UTC

   Prezado Cliente, Gostaríamos de fornecer uma atualização sobre o incidente. Nosso time de tecnologia permanece atuando na correção da instabilidade mencionada anteriormente. Reforçamos os seguintes pontos: - O Impacto está ocorrendo no acesso aos nossos Portais Unico, afetando o PortalID, UnicoPeople e IDSign - As requisições via API seguem operando normalmente As ações corretivas seguem em execução acelerada para restabelecer a estabilidade plena o quanto antes. Reiteramos nosso compromisso com a transparência e enviaremos novas informações assim que o cenário for normalizado. Atenciosamente, Equipe Unico

4. identified May 18, 2026, 01:08 PM UTC

   Prezado Cliente, Gostaríamos de fornecer uma atualização sobre o incidente. Nosso time de tecnologia permanece atuando na correção da instabilidade mencionada anteriormente. Reforçamos os seguintes pontos: - O portalID, UnicoPeople e IDSign não está mais impactados e no momento está operacional - Algumas funcionalidades do portal IDsign e UnicoPeople seguem impactadas - As requisições via API seguem operando normalmente As ações corretivas seguem em execução acelerada para restabelecer a estabilidade plena o quanto antes. Reiteramos nosso compromisso com a transparência e enviaremos novas informações assim que o cenário for normalizado. Atenciosamente, Equipe Unico

5. monitoring May 18, 2026, 02:19 PM UTC

   Prezado cliente. Identificamos a causa da instabilidade nos portais e nos disparo dos links e aplicamos as devidas correções. No momento estamos dando inicio à fase de operação assistida. Atenciosamente, Equipe Unico

6. resolved May 18, 2026, 02:35 PM UTC

   Prezado Cliente, Incidente resolvido. 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.

7. postmortem Jun 29, 2026, 01:25 PM UTC

   **Resumo** Em 18 de maio de 2026, entre 08h17 e 11h16 \(horário de Brasília\), o portal de acesso dos usuários ficou inacessível por aproximadamente 3 horas, com taxas de erro no endpoint de perfil atingindo entre 80% e 97%. O incidente foi causado pela saturação de disco em um componente de infraestrutura de filas de mensagens, que ao atingir o limite configurado bloqueou automaticamente todos os publicadores de mensagens. O alerta de disco havia sido disparado na sexta-feira anterior, mas foi enviado apenas para um único endereço de e-mail e não chegou à equipe de plantão, permitindo que o problema se agravasse ao longo do final de semana. **Impacto** Todos os usuários do portal enfrentaram timeouts de login e erros 502 durante o período. Além do portal, outros produtos que dependiam do mesmo serviço de identidade foram afetados, incluindo fluxos de criação de novos usuários, reset de senha e login em outros sistemas internos. **Causa Raiz** A causa raiz foi a saturação do espaço em disco de um dos nós do cluster de filas de mensagens. Quando o espaço livre caiu abaixo do limite configurado, o próprio sistema ativou automaticamente um bloqueio de publicação de mensagens como mecanismo de proteção contra perda de dados. Com o bloqueio ativo, um componente intermediário da rota de autenticação passou a enfileirar requisições em vez de processá-las, gerando latências de até 23 segundos nas chamadas de autenticação. O alerta havia sido emitido na sexta-feira às 10h16 — três dias antes da interrupção — mas estava configurado para notificar apenas um único endereço de e-mail não monitorado ativamente, o que permitiu que a condição persistisse sem intervenção durante todo o final de semana. **Resolução** A equipe identificou o problema no cluster de filas de mensagens às 11h05. Foram realizados o reinício do cluster e a expansão do disco. Após essas ações, a latência retornou ao normal às 11h15 e todos os serviços afetados se estabilizaram. **Lições Aprendidas** * O alerta de saturação de disco do cluster de filas de mensagens estava configurado para notificar apenas um único endereço de e-mail, sem envio para canais monitorados ativamente ou para a escala de plantão. O alerta disparou em uma sexta-feira e passou despercebido até segunda-feira, quando a saturação já havia causado uma interrupção generalizada. Expandir a cobertura de alertas de infraestrutura crítica para canais ativamente monitorados é a melhoria mais urgente identificada. * O componente de filas de mensagens era compartilhado entre múltiplos serviços — autenticação, portal e notificações via webhook — sem isolamento. A saturação de disco de um único nó causou impacto simultâneo em todos esses serviços. A segregação da infraestrutura de filas por domínio reduziria significativamente o raio de impacto de falhas futuras. * Não havia mecanismo automatizado de expansão de disco ou rotação de logs quando o uso se aproximasse do limite configurado. A dependência de intervenção manual após um alerta que não foi visto deixou o sistema vulnerável durante o final de semana. * O tempo total para identificação da causa raiz foi de aproximadamente 3 horas. A ausência de painéis ou runbooks que correlacionassem a saúde do cluster de filas de mensagens com a degradação dos serviços dependentes contribuiu para que a investigação inicial seguisse caminhos incorretos antes de convergir para o componente correto.