Instabilidade Parcial nos processos do ID - Integração By Client

Update timeline

1. investigating May 12, 2026, 08:40 PM UTC

   Prezado Cliente, Nossa monitoração identificou um impacto no retorno de requisições para uma parcela de clientes com integração By Client. O impacto está gerando latência, seguida de timeout. Nosso time de tecnologia está mobilizado para identificar e resolver o problema. Se sua operação não percebeu degradação, seus fluxos não foram afetados neste incidente. Em breve retornaremos com novas atualizações.

2. identified May 12, 2026, 08:48 PM UTC

   Prezado Cliente, Identificamos a causa da instabilidade no retorno das requisições para uma parcela de clientes com integração By Client. Nosso time de tecnologia está atuando na resolução do incidente. Em breve retornamos com atualizações.

3. monitoring May 12, 2026, 09:08 PM UTC

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou uma instabilidade que afetou o tempo de resposta das requisições para uma parcela dos usuários da integração By Client. Ocorrência: Latência intermitente seguida de timeout. Período do impacto: Das 17:04 às 17:43 (Horário de Brasília). Status atual: Serviço normalizado após a aplicação de medidas de contingência. Caso sua operação não tenha apresentado degradação no intervalo mencionado, seus fluxos não foram afetados. Continuamos monitorando o ambiente e enviaremos o relatório detalhado em breve. Atenciosamente, Equipe Unico

4. resolved May 12, 2026, 09:22 PM UTC

   Comunicado de Incidente: Encerramento e Resolução Prezado Cliente, É prioridade da Unico manter a transparência e a confiança em nossas operações. Por isso, detalhamos abaixo o encerramento do incidente ocorrido hoje. 1. Resumo Executivo e Impacto Entre 17:04 e 17:43 (Horário de Brasília), identificamos uma instabilidade que afetou o tempo de resposta das requisições para uma parcela mínima de clientes que utilizam a integração By Client. O incidente manifestou-se por meio de latência intermitente, culminando em timeouts pontuais. Reforçamos que, caso sua operação não tenha registrado um aumento no volume de erros dentro deste intervalo específico, seus fluxos não sofreram qualquer impacto. Os serviços foram restabelecidos e operam com performance normalizada, incluindo o processamento de imagem e o motor de liveness. 2. Compromisso e Próximos Passos Nossa equipe permanece monitorando rigorosamente todos os indicadores para garantir a continuidade da operação. Como parte do nosso processo de melhoria contínua, um Postmortem detalhado está sendo elaborado e será compartilhado em breve, contendo as medidas preventivas que serão adotadas para evitar recorrências. Lamentamos sinceramente qualquer inconveniente causado e agradecemos pela parceria e compreensão. Atenciosamente, Equipe Unico

5. postmortem Jun 18, 2026, 01:28 PM UTC

   **Resumo** Em 12 de maio de 2026, às 17h05 \(horário de Brasília\), tivemos um problema de conexão com a atualização automática de um dos nossos certificados, causando falhas de conectividade para usuários de mais de 25 clientes. O incidente durou aproximadamente 36 minutos e foi mitigado às 17h40 com a antecipação de uma migração de infraestrutura já planejada. A causa foi um conflito silencioso entre dois sistemas de renovação automática de certificado, introduzido por uma mudança parcial de infraestrutura realizada dias antes. **Impacto** Usuários de mais de 25 clientes que utilizavam a integração via uma camada específica da plataforma enfrentaram falhas de conexão com erros de certificado inválido. Durante o período, os usuários não conseguiam estabelecer conexões seguras com o serviço. A página de status também foi afetada quando acessada via HTTPS, impedindo que os próprios usuários verificassem o estado do serviço durante o incidente. **Causa Raiz** A causa raiz foi um erro operacional em uma migração parcial de infraestrutura. Como parte da preparação para migrar um dos domínios de serviço para um novo provedor de rede, o registro DNS responsável pela validação automática do certificado SSL foi antecipadamente movido para o novo provedor. No entanto, o domínio de API principal ainda estava operando na infraestrutura anterior, aguardando uma janela de mudança agendada para 20 de maio. Essa inconsistência fez com que o processo de renovação automática do certificado falhasse silenciosamente — o sistema tentava validar o domínio por uma rota que não reconhecia mais. O conflito não foi detectado porque o registro DNS anterior não estava gerenciado como código de infraestrutura, tornando-o invisível durante as revisões de mudança. Quando o certificado atingiu sua data de expiração, ele não foi renovado e as conexões passaram a falhar imediatamente. Um incidente similar havia ocorrido dias antes, mas a relação entre os dois eventos não foi identificada a tempo. **Resolução** A equipe identificou o certificado expirado e a causa do conflito em poucos minutos. Como a renovação automática não era mais viável no curto prazo, a decisão foi antecipar a migração do domínio para o novo provedor de rede — prevista para 20 de maio. A mudança foi executada às 17h40, restaurando o serviço. Outros domínios no mesmo estado de migração parcial foram identificados para tratamento preventivo imediato. **Lições Aprendidas** * Mudanças em registros DNS de validação de certificado no nível wildcard têm escopo amplo: afetam todos os subdomínios cobertos, não apenas o que está sendo migrado. Migrações parciais que alteram esses registros antecipadamente criam estados inconsistentes que podem falhar silenciosamente até a próxima renovação do certificado. * A ausência de monitoramento proativo de expiração de certificados foi o fator que permitiu que o problema só fosse detectado quando as conexões já estavam falhando. Alertas com antecedência de 14 a 30 dias antes da expiração são essenciais para evitar esse tipo de incidente. * Registros DNS e de validação de certificados não gerenciados como código de infraestrutura são pontos cegos: não aparecem em revisões de mudança e podem entrar em conflito com novas configurações sem que ninguém perceba. A cobertura completa desses registros em infraestrutura como código é uma melhoria estrutural prioritária. * A página de status compartilhava a mesma dependência de certificado que os serviços afetados, ficando inacessível via HTTPS durante o incidente. A página de status deve ter infraestrutura independente dos serviços que monitora para permanecer disponível justamente quando mais é necessária.