Unico Outage History

Started Feb 24, 2026, 06:47 PM UTC· resolved Feb 24, 2026, 07:27 PM UTC

1. identified Feb 24, 2026, 06:37 PM UTC

   Identificamos a causa da instabilidade na funcionalidade de Assinatura Digital da Unico (Unico SIGN) e nosso time de tecnologia está atuando para a resolução. Em breve traremos atualizações.

2. identified Feb 24, 2026, 06:47 PM UTC

   Prezado Cliente, Nossa equipe de engenharia está atuando no incidente do produto Unico Sign. Neste instante todos os clientes que consomem o serviço de assinatura da Unico, poderão ter seus processos afetados durante a criação. A equipe de tecnologia está tratando o incidente com prioridade máxima. Em breve retornamos com atualizações.

3. monitoring Feb 24, 2026, 07:02 PM UTC

   Aplicamos as medidas corretivas necessárias e o serviço de assinatura digital já apresenta comportamento estável. Permaneceremos em monitoramento rigoroso pelos próximos períodos para assegurar que a performance se mantenha nos níveis ideais.

4. resolved Feb 24, 2026, 07:27 PM UTC

   Resumo Executivo e Impacto Comunicamos que o incidente técnico que afetou as operações de assinatura de documentos no Unico Sign foi totalmente resolvido. O serviço já se encontra estabilizado e as operações foram normalizadas após o período de indisponibilidade reportado. Durante a fase de monitoramento assistido, confirmamos que o sistema recuperou sua performance integral. Ressaltamos que não houve qualquer perda de dados ou comprometimento da integridade dos documentos processados durante este evento. Causa Raiz e Resolução Nossa investigação técnica identificou que a instabilidade foi causada por um volume atípico de tentativas de reprocessamento, o que gerou uma sobrecarga na nossa camada de armazenamento de dados. Esse comportamento impediu que o sistema processasse novas assinaturas com a agilidade necessária. Para solucionar o cenário, nosso time de tecnologia executou as seguintes ações: Expansão de Recursos: Aumentamos em quatro vezes a capacidade de processamento do banco de dados para absorver a demanda acumulada. Otimização de Serviços: Reiniciamos os componentes críticos de assinatura e reajustamos a distribuição de carga do sistema para aliviar a pressão na infraestrutura, garantindo um fluxo estável e seguro. Controle de Vazão: Calibramos a comunicação entre os serviços para assegurar que a retomada das operações não gerasse novas oscilações. Compromisso e Próximos Passos A Unico prioriza a transparência e a confiabilidade de seus serviços. Por isso, nossas equipes já iniciaram a elaboração de um Postmortem detalhado, que será compartilhado nos próximos dias para fornecer uma visão técnica aprofundada e descrever as melhorias estruturais que adotaremos para evitar recorrências. Lamentamos o transtorno causado e seguimos à disposição através de nossos canais de atendimento para qualquer suporte adicional. Atenciosamente, Equipe Unico

5. postmortem Mar 06, 2026, 01:27 PM UTC

   ## Relatório Pós-Incidente: Instabilidade no Serviço de Assinatura de Documentos **Data:** 24 de fevereiro de 2026 **Status:** Resolvido ### Resumo No dia 24 de fevereiro de 2026, nosso serviço de assinatura de documentos apresentou instabilidade significativa devido a uma latência excessiva no método de execução de módulos. O problema foi desencadeado por um volume atípico de requisições que sobrecarregou a base de dados, resultando em falhas nas operações de assinatura baseadas em envelopes. ### Impacto Durante o período do incidente, todas as operações de assinatura de documentos que utilizavam fluxos de envelopes foram interrompidas. Isso causou uma interrupção total nos fluxos de trabalho de clientes que dependiam da conclusão de assinaturas digitais em tempo real. ### Causa Raiz A investigação técnica identificou um erro de software no componente de interface \(frontend\). Uma falha na implementação de um gancho de renderização \(`useEffect`\) fez com que uma função de busca de dados fosse tratada como uma nova dependência a cada ciclo de atualização. Como a função era declarada de forma embutida, sua referência mudava a cada renderização do componente pai, criando um **loop infinito de requisições**. Esse comportamento gerou um tráfego massivo para a API, resultando em consultas intensivas na tabela de acessos do banco de dados e levando à degradação total da performance do sistema. ### Resolução Para restabelecer o serviço, nossa equipe de engenharia adotou as seguintes medidas de mitigação: * **Escalonamento de Infraestrutura:** A capacidade do banco de dados foi aumentada temporariamente de 8 vCPU para 32 vCPU para absorver a carga e processar a fila de requisições pendentes. * **Reciclagem de Serviços:** Os pods responsáveis pelo núcleo de assinatura e pelo processamento de tarefas em segundo plano foram reiniciados para limpar conexões presas e reduzir a carga do sistema. * **Ajuste de Carga:** O número de réplicas do serviço de assinatura foi reduzido temporariamente para controlar a quantidade de conexões simultâneas ao banco de dados até que a estabilidade fosse alcançada. O serviço foi declarado estável e totalmente restabelecido após o monitoramento dos indicadores de performance. ### Lições Aprendidas * **Gestão de Dependências em UI:** Reforçamos a necessidade de utilizar padrões de memorização \(como `useCallback`\) para funções passadas como dependências em efeitos, evitando execuções redundantes ou loops. * **Mecanismos de Proteção \(Guards\):** Identificamos a oportunidade de implementar camadas de proteção no armazenamento de dados \(store\) para impedir chamadas concorrentes idênticas enquanto uma requisição ainda está em processamento. * **Observabilidade de Transações:** O incidente destacou a importância de enriquecer os logs de transação com identificadores mais granulares para acelerar o diagnóstico em cenários de requisições duplicadas.

Read the full incident report →

Started Feb 17, 2026, 06:00 PM UTC· resolved Feb 17, 2026, 06:00 PM UTC

1. resolved Feb 17, 2026, 07:48 PM UTC

   Resumo Executivo: No dia 17 de fevereiro de 2026, nosso sistema enfrentou uma instabilidade temporária causada por um volume atípico de requisições em um curto período, entre 14:48 e 15:09. Este pico de tráfego sobrecarregou o sistema de mensageria, resultando em timeouts que interromperam o processamento de captura de dados. Como consequência, alguns clientes observaram um aumento em erros de limite de taxa (HTTP 429) e latência elevada em determinados endpoints durante o período de maior demanda. A resolução foi alcançada através da reinicialização dos serviços afetados e do escalonamento de recursos para absorver a carga excedente. Após as medidas de mitigação, o ambiente foi monitorado continuamente e apresenta estabilidade plena há mais de 30 minutos, sem novas ocorrências. Estamos revisando nossos mecanismos de resiliência e tolerância a falhas no processamento de eventos para garantir que o sistema lide de forma mais autônoma com flutuações severas de tráfego no futuro. 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!

2. postmortem Mar 09, 2026, 05:32 PM UTC

   ## Relatório de Incidente: Instabilidade no Serviço de entrega de WebHook \(IDCloud\) ### Resumo Em 17 de fevereiro de 2026, nosso serviço de notificação de eventos \(Webhooks\) apresentou instabilidade e queda na taxa de sucesso, operando abaixo da meta estabelecida de **97,6%**. O incidente foi desencadeado por uma falha técnica no componente de captura de dados, que parou de processar eventos devido a uma instabilidade externa. Após o restabelecimento manual do serviço, o volume acumulado de mensagens causou uma sobrecarga temporária em nossa infraestrutura de entrega. ### Impacto * **Duração do Impacto Total:** Aproximadamente 1 hora e 7 minutos. * **Serviços Afetados:** Fluxo de criação de eventos via Webhook. * **Experiência do Cliente:** Alguns clientes enfrentaram atrasos no recebimento de notificações de finalização de jornada. Devido a esse atraso, houve um aumento nas tentativas manuais de reprocessamento e consultas de status \(GET\), o que resultou em erros temporários de limite de taxa \(_rate limiting_ - HTTP 429\). ### Causa Raiz O incidente foi originado por uma combinação de fatores técnicos e de infraestrutura: 1. **Instabilidade Externa:** Uma oscilação transiente na infraestrutura de mensageria em nuvem \(Pub/Sub\) causou falhas de conexão no worker de processamento. 2. **Falha na Recuperação Automática:** Devido à ausência de configurações específicas de tempo limite de encerramento \(_shutdown timeout_\) e de verificações de integridade, o serviço entrou em um estado de "travamento" silencioso. Ele parou de consumir dados, mas não reiniciou automaticamente para recuperar a conexão. 3. **Efeito Cascata:** Durante os 18 minutos em que o serviço ficou inativo, uma grande quantidade de eventos acumulou-se na fila. Ao ser reiniciado manualmente, o sistema tentou processar todo o backlog de uma só vez, gerando um pico de tráfego que saturou as conexões do banco de dados do serviço de webhook. ### Resolução A mitigação foi realizada por nossa equipe de engenharia de confiabilidade \(SRE\) através do **reinício manual dos serviços travados**. Após o restart, o sistema passou por um período de instabilidade enquanto drenava o backlog acumulado, estabilizando-se completamente às 15h55 BRT. O monitoramento subsequente confirmou que a taxa de sucesso retornou aos níveis normais de SLO e o volume de requisições dos clientes foi normalizado. ### Lições Aprendidas * **Resiliência a Falhas Externas:** Identificamos que o componente de captura de dados precisa de configurações de _timeout_ mais agressivas para garantir que o processo finalize e reinicie em caso de latência de rede externa. * **Necessidade de Throttling:** A ausência de um mecanismo de controle de vazão \(_throttling_\) na drenagem de backlogs torna o sistema vulnerável a surtos de tráfego após períodos de inatividade. * **Automação do MTTR:** Depender de intervenção manual e escalonamento de permissões aumenta o tempo médio de recuperação \(MTTR\). A implementação de verificações de saúde automatizadas é essencial para a autorrecuperação.

Read the full incident report →

Started Feb 10, 2026, 06:37 PM UTC· resolved Feb 10, 2026, 08:38 PM UTC

1. identified Feb 10, 2026, 06:37 PM UTC

   Prezado Cliente, Identificamos uma instabilidade que afeta o acesso à plataforma Unico Auto. Nossa equipe de engenharia já está mobilizada e trabalha prioritariamente na identificação da causa e na implementação das correções necessárias. Lamentamos o inconveniente e forneceremos novas atualizações em breve.

2. identified Feb 10, 2026, 07:09 PM UTC

   Atualização: Instabilidade na plataforma Unico Auto Prezado Cliente, Informamos que nossa equipe de engenharia segue trabalhando ativamente na análise da instabilidade que afeta o acesso à plataforma Unico Auto. No momento, os especialistas permanecem dedicados ao diagnóstico técnico para garantir que a correção seja implementada de forma definitiva. Lamentamos a extensão do impacto e reforçamos que este caso é tratado como prioridade máxima. Novas atualizações serão compartilhadas assim que houver evolução no processo de normalização.

3. identified Feb 10, 2026, 08:13 PM UTC

   Atualização: Instabilidade no acesso à plataforma Status: Em investigação Seguimos analisando a instabilidade no processo de login do Unico Auto. O cenário permanece o mesmo: usuários com múltiplas instâncias podem enfrentar dificuldades de acesso, enquanto outros perfis podem precisar recarregar a página para entrar no sistema. Nossa equipe de engenharia continua dedicada à identificação da causa raiz e na definição da estratégia de correção. As demais funcionalidades seguem operando normalmente. Traremos novas atualizações em breve.

4. monitoring Feb 10, 2026, 08:37 PM UTC

   Atualização de Incidente: Em Monitoramento Após as correções aplicadas por nossa engenharia, os serviços da plataforma Unico Auto foram retomados. Permanecemos em estágio de monitoramento preventivo para validar a eficácia das soluções e assegurar que o fluxo de operações siga sem oscilações. Nova atualização assim que a estabilidade integral for confirmada.

5. resolved Feb 10, 2026, 08:38 PM UTC

   Prezado Cliente, O incidente técnico que impactou a plataforma Unico Auto foi resolvido. O sistema operou sem intercorrências durante a fase de monitoramento, o que confirma a normalização do serviço. Próximos passos: Iniciamos o processo de análise pós-incidente para identificar melhorias estruturais e evitar recorrências. Valorizamos sua parceria e seguimos à disposição pelos canais de suporte habituais.

Read the full incident report →

Started Feb 10, 2026, 06:29 PM UTC· resolved Feb 10, 2026, 07:59 PM UTC

1. identified Feb 10, 2026, 06:29 PM UTC

   Instabilidade nos serviços de Prova de Vida (Liveness) Resumo do Incidente: Detectamos uma oscilação na disponibilidade dos serviços de liveness, impactando as taxas de sucesso das requisições de liveness da Unico. Impacto ao Cliente: Clientes que utilizam essas funcionalidades via SDK podem encontrar dificuldades ou falhas intermitentes ao realizar processos de captura e validação biométrica. Ações em Andamento: Nossa equipe de engenharia já identificou a origem da instabilidade e está trabalhando na mitigação. Como primeira medida corretiva, estamos realizando o escalonamento de serviços para normalizar o processamento das requisições. Próximos Passos: Seguimos com a investigação técnica para determinar a causa raiz e garantir a estabilidade total do ambiente. Traremos novas atualizações assim que houver mudança no status ou a normalização do serviço.

2. identified Feb 10, 2026, 06:49 PM UTC

   We are continuing to work on a fix for this issue.

3. identified Feb 10, 2026, 07:08 PM UTC

   Atualização: Instabilidade nos serviços de Liveness Status: Em investigação Componentes Afetados: Liveness Informações Atualizadas: Seguimos trabalhando na resolução da instabilidade que afeta os serviços de Liveness. O cenário reportado anteriormente permanece, com a disponibilidade operando abaixo dos níveis normais devido a falhas na captura e validação de biometria. Ações em curso: Nossa equipe de engenharia continua atuando diretamente na infraestrutura para estabilizar o serviço. O processo de escalonamento dos recursos críticos segue sendo monitorado para mitigar o impacto nas requisições via SDK. Permanecemos em análise intensiva para garantir o reestabelecimento da taxa de sucesso. Novas atualizações serão fornecidas assim que houver evolução na recuperação do serviço.

4. identified Feb 10, 2026, 07:33 PM UTC

   Informações Atualizadas: Seguimos com o monitoramento e a análise técnica da instabilidade que afeta os serviços de captura de dados e biometria (Liveness). O cenário de oscilação reportado anteriormente persiste, e nossa equipe permanece dedicada à solução. Ações em curso: - Nossos times de engenharia continuam mobilizados com prioridade máxima na correção do problema. - Estamos aplicando medidas de reforço em nossa infraestrutura para normalizar a taxa de sucesso das validações. - O serviço permanece sob observação constante até que a estabilidade total seja confirmada. Lamentamos o impacto causado e reforçamos que todos os esforços estão sendo empenhados para o restabelecimento completo da operação. Traremos novas informações assim que houver evolução no cenário.

5. monitoring Feb 10, 2026, 07:52 PM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado, o ambiente retornou a sua normalidade a partir das 16:25. 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!

6. resolved Feb 10, 2026, 07:59 PM UTC

   Resumo Executivo Impacto: Informamos que, no dia 10 de fevereiro, identificamos uma instabilidade nos serviços de Prova de Vida (Liveness) iniciada às 15h06. O incidente resultou em falhas intermitentes e aumento de latência para uma parcela das validações biométricas. Após a atuação prioritária do nosso time de engenharia, a disponibilidade foi totalmente restabelecida às 16h25, momento em que os indicadores de sucesso retornaram aos níveis operacionais normais. Resolução e Investigação: A mitigação do impacto foi alcançada através da identificação e reinicialização de componentes da nossa infraestrutura de processamento que apresentavam comportamento degradado. No momento, os serviços operam com estabilidade e seguem sob monitoramento rigoroso. Próximos Passos: Nossa equipe técnica permanece dedicada à investigação profunda para determinar a causa raiz desta oscilação, incluindo a análise conjunta com nossos provedores de infraestrutura. Em breve, disponibilizaremos um relatório pós-incidente (post-mortem) detalhando os achados técnicos e as ações preventivas adotadas. Reiteramos nosso compromisso com a transparência e com a melhoria contínua de nossa plataforma para garantir a melhor experiência e confiabilidade aos nossos clientes. Equipe Unico.

7. postmortem Mar 16, 2026, 01:18 PM UTC

   # Postmortem: Instabilidade nos fluxos de Prova de Vida \(Liveness\) ### Resumo No dia 10 de fevereiro de 2026, identificamos uma instabilidade em nossa camada de orquestração de liveness \(biometria facial\), que resultou em erros intermitentes \(HTTP 500\) para diversas funcionalidades. O incidente foi provocado por falhas de comunicação interna entre microsserviços após um evento de rebalanceamento de infraestrutura. A situação foi normalizada após a reinicialização estratégica de instâncias do serviço afetado. ‌ ### Impacto O incidente teve início às **12:07 BRT** e foi totalmente mitigado às **16:37 BRT**. Durante esse período, usuários podem ter enfrentado lentidão ou falhas ao tentar realizar fluxos de captura de dados e validação biométrica. O erro manifestava-se como um _timeout_ de 10 segundos quando o sistema tentava se comunicar com capacidades internas específicas. ‌ ### Causa Raiz A investigação técnica revelou uma falha na propagação de atualizações de rede dentro do nosso cluster de serviços \(Istio/ASM\). ‌ 1. **Evento de Infraestrutura:** Cerca de 15 nós de processamento foram removidos simultaneamente durante um processo de redimensionamento automático \(_scale-down_\) na nuvem. 2. **Sobrecarga do Plano de Controle:** A remoção abrupta de mais de 46 pods gerou uma carga de eventos de rede três vezes maior que o normal, sobrecarregando o sistema de controle de tráfego. 3. **Endpoints Obsoletos:** Devido a essa sobrecarga, alguns serviços tentaram enviar tráfego para endereços de IP de instâncias que já haviam sido encerradas, resultando em falhas de conexão e _timeouts_. 4. **Ausência de Limites de Evicção:** A inexistência de configurações de orçamento de interrupção \(_PodDisruption Budget_\) permitiu que muitos componentes críticos fossem removidos ao mesmo tempo, impedindo uma transição gradual da rede. ### Resolução A equipe de engenharia identificou três instâncias do orquestrador que mantinham registros de rede inconsistentes. Às **16:00 BRT**, foi realizado o _restart_ dessas instâncias, o que forçou a atualização das tabelas de roteamento e cessou imediatamente os erros 5xx. O sistema retornou à estabilidade total logo em seguida. ‌ ### Lições Aprendidas * **Gerenciamento de Escala:** Identificamos a necessidade de implementar mecanismos de remoção gradual de instâncias para evitar picos de carga no plano de controle de rede. * **Resiliência de Configuração:** A importância de utilizar políticas de interrupção de pods para garantir que serviços críticos nunca fiquem abaixo de um limiar mínimo de disponibilidade durante manutenções automáticas. * **Observabilidade:** Reforçamos a necessidade de alertas específicos sobre a taxa de eventos de processamento interno para detectar sobrecargas antes que elas impactem o usuário final. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Feb 10, 2026, 01:23 PM UTC· resolved Feb 10, 2026, 02:14 PM UTC

1. investigating Feb 10, 2026, 01:23 PM UTC

   Prezados Clientes, Identificamos uma instabilidade intermitente na funcionalidade de Prova de Vida e Captura do produto ID Pay. Nossa equipe de engenharia já está atuando na investigação para normalizar o serviço o quanto antes. Impacto: Clientes podem encontrar dificuldades ou lentidão ao realizar o processo de captura biométrica. Status: Investigando

2. identified Feb 10, 2026, 01:35 PM UTC

   Prezado Cliente, Informamos que o fluxo de captura do ID Pay apresenta instabilidade no momento. O diagnóstico técnico já foi concluído e as ações corretivas estão sendo implementadas com prioridade máxima por nosso time de especialistas. Status: Em correção.

3. monitoring Feb 10, 2026, 02:01 PM UTC

   Atualização: Após a implementação de medidas corretivas, o serviço de Prova de Vida e Captura do ID Pay foi estabilizado. Nossa equipe técnica permanece monitorando o ambiente para garantir a plena disponibilidade e performance da funcionalidade. Status: Monitorando.

4. resolved Feb 10, 2026, 02:14 PM UTC

   Instabilidade na Captura de Biometria Facial no ID Pay Sumário Executivo e Impacto: No dia de hoje, identificamos uma instabilidade técnica que afetou a funcionalidade de captura de biometria facial em nossa jornada do produto lD Pay. Os primeiros registros de falha ocorreram por volta das 06h40, fazendo com que uma parcela dos usuários enfrentasse dificuldades ao acionar a câmera do dispositivo, impossibilitando a conclusão do fluxo de validação. Após as ações de contingência, o impacto foi integralmente cessado às 10h40, e o sistema permanece desde então com operação normalizada e taxas de sucesso estáveis. Causa Raiz e Resolução: A instabilidade foi causada por uma incompatibilidade técnica em uma atualização de software no kit de desenvolvimento (SDK) de captura de imagem. Esta versão apresentou um erro de execução que impedia o carregamento de recursos nativos da câmera em cenários específicos. Como medida de resolução, nossa equipe de engenharia realizou o rollback para a versão estável anterior, restaurando a funcionalidade. Compromisso e Próximos Passos: Reforçamos nosso compromisso com a estabilidade de nossos serviços e com a transparência junto aos nossos clientes. Informamos que, nos próximos dias, será disponibilizado um postmortem detalhado com a análise técnica completa e as medidas preventivas adotadas para evitar recorrências. Atenciosamente, Equipe Unico.

5. postmortem Mar 10, 2026, 07:59 PM UTC

   **Data do Incidente:** 10 de fevereiro de 2026 **Duração do Impacto:** 06:30 às 11:31 \(Horário de Brasília\) **Status:** Resolvido ### Resumo Executivo Em 10 de fevereiro de 2026, nossa plataforma de pagamentos enfrentou uma falha que impediu a inicialização do fluxo de captura de biometria facial. O incidente foi desencadeado por uma nova validação de segurança introduzida na atualização recente do nosso Web SDK de biometria. A equipe de engenharia isolou a falha e normalizou o serviço após reverter \(aplicar _rollback_\) a versão do componente na infraestrutura. ### Impacto Durante o período de degradação, os clientes finais não conseguiram concluir os processos que exigiam a captura facial. A falha na renderização gerou uma tela em branco no carregamento da câmera, sem o devido mapeamento de erros visíveis, o que prejudicou a geração de alertas automatizados no monitoramento padrão. O impacto iniciou às 06:30, mas, pela ausência de alarmes de sistema, o problema só foi confirmado às 10:12 a partir do aumento de contatos dos clientes aos canais de suporte. A estabilização completa ocorreu às 11:31. ### Causa Raiz A instabilidade foi causada por uma incompatibilidade técnica entre uma biblioteca de terceiros e a nova camada de validação do Web SDK de captura. * A versão atualizada do Web SDK introduziu uma checagem de integridade que avalia se operações nativas do JavaScript foram modificadas por outras bibliotecas. * A plataforma de pagamentos utiliza uma biblioteca que realiza uma modificação em uma função estrutural nativa da web. * Ao detectar essa modificação de terceiros, o SDK lançou imediatamente um erro de segurança e bloqueou o carregamento da câmera. A incompatibilidade não foi percebida durante os testes pré-implantação \(ambiente de homologação\) devido a uma regra temporária que dividia o tráfego do ambiente em 50% entre dois provedores de biometria diferentes. As capturas com sucesso foram roteadas para o provedor secundário, mascarando o erro na nova versão do componente principal sob teste. ### Resolução Ao confirmar a falha na atualização, a equipe de engenharia iniciou imediatamente a reversão \(_rollback_\) do Web SDK de biometria para a sua versão anterior estável. O tempo de resolução, no entanto, foi prolongado devido a uma inconsistência na execução do _rollback_ em nossos ambientes distribuídos geograficamente. A reversão falhou na propagação inicial para uma das regiões de infraestrutura em nuvem, mantendo erros isolados por cerca de 40 minutos adicionais. Ao identificar o tráfego de falhas residual nessa região, a equipe forçou a atualização do ambiente de forma isolada, mitigando completamente o problema. ### Ações Preventivas Para fortalecer a governança técnica da nossa plataforma e evitar cenários semelhantes, os seguintes passos foram incorporados ao planejamento de engenharia: * **Cobertura de Reversões:** Aprimorar o processo automatizado de reversões \(_rollbacks_\) para garantir de forma explícita que atualizações de contingência sejam simultaneamente aplicadas e validadas em todas as regiões globais. * **Paridade de Ambientes:** Ajustar as políticas de balanceamento do ambiente de testes para que componentes críticos em fase de avaliação recebam 100% da carga de tráfego esperada, desativando regras de divisão estatística que possam mascarar falhas. * **Mapeamento de Exceções:** Refatorar o mecanismo de tratamento de exceções do Web SDK, assegurando que quaisquer colisões ou falhas graves de componentes gerem retornos \(callbacks\) mensuráveis de erro ao invés de encerramentos silenciosos \(como telas em branco\). ### Lições Aprendidas * **Rigor em Ambientes de Homologação:** Processos de roteamento dividido \(como Testes A/B\) implementados diretamente na camada de rede da homologação podem invalidar a precisão dos testes de regressão. É imperativo que os testes reflitam com fidelidade o uso real. * **Complexidade Multi-Região:** Intervenções manuais ou parciais em infraestruturas baseadas em múltiplas regiões na nuvem são inerentemente propensas a falhas humanas. Mitigações críticas exigem ferramentas de orquestração atômica \(aplicando a todos ou nenhum\). * **Importância Crítica da Observabilidade:** Sistemas voltados para interação de usuários precisam falhar de forma explícita e mapeável. Falhas silenciosas prolongam significativamente a detecção de incidentes, transferindo a notificação do problema para os canais de atendimento ao cliente, ao invés do monitoramento pró-ativo de sistemas.

Read the full incident report →

Started Feb 10, 2026, 12:08 PM UTC· resolved Feb 10, 2026, 04:20 PM UTC

1. investigating Feb 10, 2026, 12:08 PM UTC

   Alerta de Serviço: Unico Auto Detectamos uma interrupção parcial nos serviços da plataforma Unico Auto. Impacto: Dificuldade de login e lentidão em funcionalidades gerais. Status: Equipe técnica mobilizada em diagnóstico e correção. Estamos trabalhando para restabelecer o ambiente o mais breve possível.

2. identified Feb 10, 2026, 02:18 PM UTC

   Atualização: Comunicamos que nossa equipe de engenharia identificou uma interrupção parcial nos serviços da plataforma Unico Auto, que pode ocasionar dificuldades de login e lentidão em funcionalidades gerais. Informamos que o incidente já foi formalmente diagnosticado e nossas equipes técnicas seguem mobilizadas, com foco total na identificação da causa raiz e na implementação da resolução definitiva. Estamos trabalhando com prioridade máxima para restabelecer a estabilidade integral do ambiente o mais breve possível.

3. identified Feb 10, 2026, 03:03 PM UTC

   Atualização: Nossas equipes de engenharia permanecem atuando de forma ininterrupta na resolução da instabilidade que afeta o Unico Auto. O diagnóstico inicial já foi concluído e, no momento, estamos concentrados na fase de remediação para normalizar o acesso ao login e o desempenho da plataforma. Reiteramos que a estabilização deste ambiente é nossa prioridade atual.

4. monitoring Feb 10, 2026, 04:13 PM UTC

   Atualização – Ambiente em Monitoramento: Informamos que as correções necessárias foram implementadas e a estabilidade da plataforma Unico Auto foi restabelecida. O acesso ao login e as demais funcionalidades já operam normalmente. No momento, nossas equipes técnicas permanecem monitorando o comportamento do sistema para garantir a consistência da operação e evitar novas oscilações.

5. monitoring Feb 10, 2026, 04:19 PM UTC

   Comunicamos que o incidente técnico que afetava o login e a performance da plataforma Unico Auto foi totalmente resolvido. Após um período de monitoramento sem novas ocorrências, confirmamos a estabilidade integral do sistema. Nossa equipe de engenharia já iniciou a análise de causa raiz para implementar melhorias que evitem futuras instabilidades. Reforçamos que nossa prioridade é garantir a continuidade e a qualidade de nossas operações. Atenciosamente, Unico Auto.

6. resolved Feb 10, 2026, 04:20 PM UTC

   Comunicamos que o incidente técnico que afetava o login e a performance da plataforma Unico Auto foi totalmente resolvido. Após um período de monitoramento sem novas ocorrências, confirmamos a estabilidade integral do sistema. Nossa equipe de engenharia já iniciou a análise de causa raiz para implementar melhorias que evitem futuras instabilidades. Reforçamos que nossa prioridade é garantir a continuidade e a qualidade de nossas operações. Atenciosamente, Unico Auto.

Read the full incident report →

Started Feb 02, 2026, 01:00 PM UTC· resolved Feb 04, 2026, 09:00 PM UTC

1. identified Feb 05, 2026, 08:28 PM UTC

   Impacto O incidente afetou diretamente a experiência do assinante final. Durante o período de impacto, 100% dos envelopes contendo múltiplos documentos apresentaram erro no momento da submissão da assinatura. Período: De 02/02 às 10h até 04/02 às 18h.Volume de Impacto: Foram registradas 17.381 tentativas de assinatura que falharam devido a este comportamento.Escopo: O erro ocorreu exclusivamente no funil de assinatura (interface do usuário) para qualquer cliente que utilizasse jornadas multidocumentos. Causa Raiz A investigação técnica identificou um erro de lógica no processamento de dados do back-end após uma atualização de sistema realizada na manhã de segunda-feira (02/02). O bug causava uma divergência na comunicação com o front-end: o sistema sinalizava incorretamente que todos os documentos do envelope já haviam sido lidos e aceitos pelo assinante, sem que o evento de aceite real fosse registrado. No momento da submissão final, a camada de validação de segurança bloqueava a transação por detectar a ausência desses aceites obrigatórios, resultando em erro para o usuário. Compromisso Unico: Lamentamos o impacto causado aos assinantes e à fluidez dos negócios de nossos clientes. A transparência sobre nossas falhas é o que nos permite fortalecer nossos processos e garantir um ambiente cada vez mais robusto. Atenciosamente, Equipe Unico

2. resolved Feb 05, 2026, 08:29 PM UTC

   Relatório Pós-Incidente: Falha na Finalização de Assinaturas Multidocumentos Resumo Executivo Entre os dias 02 e 04 de fevereiro de 2026, identificamos uma instabilidade que afetou usuários em jornadas de assinatura digital. O incidente impediu a conclusão de assinaturas em envelopes que continham dois ou mais documentos. O fluxo de assinatura para envelopes com documento único permaneceu operacional e não houve impacto na criação de novos processos via API. A correção foi aplicada através de um rollback de versão, normalizando o serviço integralmente. Impacto O incidente afetou diretamente a experiência do assinante final. Durante o período de impacto, 100% dos envelopes contendo múltiplos documentos apresentaram erro no momento da submissão da assinatura. Período: De 02/02 às 10h até 04/02 às 18h.Volume de Impacto: Foram registradas 17.381 tentativas de assinatura que falharam devido a este comportamento.Escopo: O erro ocorreu exclusivamente no funil de assinatura (interface do usuário) para qualquer cliente que utilizasse jornadas multidocumentos. Causa Raiz A investigação técnica identificou um erro de lógica no processamento de dados do back-end após uma atualização de sistema realizada na manhã de segunda-feira (02/02). O bug causava uma divergência na comunicação com o front-end: o sistema sinalizava incorretamente que todos os documentos do envelope já haviam sido lidos e aceitos pelo assinante, sem que o evento de aceite real fosse registrado. No momento da submissão final, a camada de validação de segurança bloqueava a transação por detectar a ausência desses aceites obrigatórios, resultando em erro para o usuário. Resolução e Ações Corretivas Assim que a causa raiz foi isolada e vinculada à última atualização, a equipe de engenharia executou um rollback imediato para a versão estável anterior. Ação de Contorno: Reversão da versão de produção concluída às 18h do dia 04/02.Medida Preventiva: Estamos reforçando nossas camadas de testes de integração e validação de jornadas ponta a ponta (e2e), com foco específico em cenários de múltiplos documentos, para garantir que falhas de sincronia entre serviços sejam detectadas antes de qualquer deploy em ambiente produtivo. Compromisso Unico: Lamentamos o impacto causado aos assinantes e à fluidez dos negócios de nossos clientes. A transparência sobre nossas falhas é o que nos permite fortalecer nossos processos e garantir um ambiente cada vez mais robusto. Atenciosamente, Equipe Unico

3. postmortem Feb 25, 2026, 11:36 AM UTC

   # Postmortem: Instabilidade na assinatura digital com multidocumentos na jornada do By Unico ## Resumo Na segunda-feira, 2 de fevereiro de 2026, uma atualização de rotina na plataforma de assinaturas digitais introduziu um comportamento inesperado que impedia a conclusão de envelopes contendo mais de um documento. O incidente foi identificado e mitigado através da reversão da atualização \(rollback\), restabelecendo a estabilidade total do serviço. ## Impacto O incidente afetou usuários que tentavam realizar assinaturas em fluxos que envolviam múltiplos arquivos em um único envelope. ‌ * **Duração do Impacto:** Aproximadamente 56 horas entre a implantação e a mitigação. * **Volume de Erros:** Foram registrados 17.381 erros de validação durante o processo de tentativa de assinatura. * **Experiência do Usuário:** O sistema permitia incorretamente que o usuário avançasse para a etapa final de assinatura sem o aceite formal de todos os documentos, resultando em uma falha de "pré-condição" no momento da submissão. ## Causa Raiz A falha foi originada por um erro na lógica de processamento de dados do backend na versão implantada. ‌ * **Falha de Comunicação Interna:** O sistema passou a retornar apenas os eventos de aceite relativos ao primeiro documento do envelope, ignorando os demais. * **Inconsistência na Interface:** Devido a essa resposta incompleta do servidor, a interface do usuário \(front-end\) interpretava erroneamente que todos os documentos já haviam sido aceitos. * **Erro de Validação:** Como o aceite real não havia ocorrido para todos os itens, o motor de regras de segurança bloqueava a finalização da assinatura para garantir a conformidade e integridade do processo. ## Resolução Após a identificação do padrão de erros em envelopes multi-documentos, a equipe de engenharia optou pelo **rollback imediato** para a versão estável anterior. ‌ * **Início do Impacto:** 02/02/2026 às 10:00. * **Identificação:** 04/02/2026 às 16:20. * **Correção \(Rollback\):** 04/02/2026 às 18:00. ## Lições Aprendidas ‌ * **Refinamento de Monitoramento:** Identificamos a necessidade de melhorar os indicadores de nível de serviço \(SLIs\) especificamente para os métodos de assinatura, permitindo uma detecção mais rápida de anomalias em fluxos complexos. * **Testes de Regressão:** O incidente destacou a importância de ampliar a cobertura de testes automatizados para cenários que envolvam múltiplos documentos, garantindo que a paridade de dados entre backend e frontend seja validada em todas as condições. * **Visibilidade de Erros de Validação:** A análise dos logs de erro foi fundamental para isolar a causa raiz, reforçando o valor de manter logs detalhados e estruturados para diagnósticos rápidos. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 27, 2026, 12:10 PM UTC· resolved Jan 27, 2026, 02:11 PM UTC

1. identified Jan 27, 2026, 12:10 PM UTC

   Prezado Cliente, Nossos sistemas estão temporariamente indisponíveis para acesso. Nossa equipe técnica foi notificada e está trabalhando ativamente para restaurar o serviço. Todos os usuários poderão enfrentar dificuldades para acessar a plataforma.

2. monitoring Jan 27, 2026, 01:47 PM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento.

3. resolved Jan 27, 2026, 02:11 PM UTC

   Prezado Cliente, Incidente Resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento.

Read the full incident report →

Started Jan 26, 2026, 09:53 PM UTC· resolved Jan 26, 2026, 09:58 PM UTC

1. identified Jan 26, 2026, 09:26 PM UTC

   Prezado cliente, Estamos com indisponibilidade na funcionalidade Getselfie. O impacto é restrito aos usuários que tentam acessar este recurso específico, recebendo erros de carregamento ou ausência de dados. Esta é uma indisponibilidade resultante da desativação de uma configuração global para proteger a estabilidade do banco de dados principal devido ao incidente anterior. Nosso time ja esta trabalhando para reestabelecer o serviço.

2. monitoring Jan 26, 2026, 09:53 PM UTC

   Ambiente normalizado. Resumo Executivo e Impacto A funcionalidade de getselfie foi totalmente restabelecida e o serviço opera agora em níveis normais de desempenho. Após um breve período de indisponibilidade parcial do recurso — necessário para garantir a integridade da infraestrutura — a correção técnica foi aplicada com sucesso. Não há mais relatos de latência ou erros nas consultas de detalhes de processos para a base de clientes. Causa Raiz e Resolução A resolução definitiva foi alcançada através da implementação de um hotfix que otimizou a lógica de consulta ao banco de dados, adicionando os filtros de partição necessários que estavam ausentes. Com a eficiência da consulta garantida, a configuração de funcionalidade (feature flag) foi reativada de forma segura. O sistema foi monitorado durante a reativação e não apresentou novos picos de consumo de memória ou contenção de leitura, confirmando a eficácia da correção aplicada. Duração das 16h15m as 18h43m

3. monitoring Jan 26, 2026, 09:57 PM UTC

   Ambiente normalizado. Resumo Executivo e Impacto A funcionalidade de getselfie foi totalmente restabelecida e o serviço opera agora em níveis normais de desempenho. Após um breve período de indisponibilidade parcial do recurso — necessário para garantir a integridade da infraestrutura — a correção técnica foi aplicada com sucesso. Não há mais relatos de latência ou erros nas consultas de detalhes de processos para a base de clientes. Causa Raiz e Resolução A resolução definitiva foi alcançada através da implementação de um hotfix que otimizou a lógica de consulta ao banco de dados, adicionando os filtros de partição necessários que estavam ausentes. Com a eficiência da consulta garantida, a configuração de funcionalidade (feature flag) foi reativada de forma segura. O sistema foi monitorado durante a reativação e não apresentou novos picos de consumo de memória ou contenção de leitura, confirmando a eficácia da correção aplicada. Duração das 16h15m as 18h43m

4. resolved Jan 26, 2026, 09:58 PM UTC

   Ambiente normalizado. Resumo Executivo e Impacto A funcionalidade de getselfie foi totalmente restabelecida e o serviço opera agora em níveis normais de desempenho. Após um breve período de indisponibilidade parcial do recurso — necessário para garantir a integridade da infraestrutura — a correção técnica foi aplicada com sucesso. Não há mais relatos de latência ou erros nas consultas de detalhes de processos para a base de clientes. Causa Raiz e Resolução A resolução definitiva foi alcançada através da implementação de um hotfix que otimizou a lógica de consulta ao banco de dados, adicionando os filtros de partição necessários que estavam ausentes. Com a eficiência da consulta garantida, a configuração de funcionalidade (feature flag) foi reativada de forma segura. O sistema foi monitorado durante a reativação e não apresentou novos picos de consumo de memória ou contenção de leitura, confirmando a eficácia da correção aplicada. Duração das 16h15m as 18h43m

5. postmortem Feb 05, 2026, 12:57 PM UTC

   # Postmortem: ## **Resumo** No dia 26 de janeiro de 2026, entre **15:10 e 16:10**, nosso serviço de autenticação e processamento \(TCA\) apresentou degradação significativa, resultando em alta latência e erros de conexão para diversos clientes. O incidente foi desencadeado por uma saturação no pool de recursos do banco de dados, causada por consultas ineficientes durante um processo de migração de dados e agravada por uma configuração de funcionalidade específica. ## **Impacto** * **Duração:** 1 hora. * **Serviços Afetados:** O portal de gerenciamento e as APIs de consulta de detalhes de processos e selfies. * **Experiência do Usuário:** Clientes enfrentaram erros de timeout \(500\) e falhas na conclusão de jornadas que dependiam da visualização de dados de biometria. * **Escopo:** Inicialmente limitado a consultas específicas, o problema evoluiu para uma degradação generalizada de todas as jornadas do serviço devido ao esgotamento de conexões do banco de dados. ## **Causa Raiz** A causa raiz foi a **saturação de recursos no banco de dados**. 1. **Consultas Ineficientes:** Durante uma migração de dados, o volume de requisições aumentou, executando consultas em tabelas particionadas sem a identificação do índice de partição. 2. **Full Scans:** Sem o índice, o banco realizava varreduras completas em mais de 300 partições para cada busca, consumindo rapidamente o pool de "locks" disponíveis. 3. **Efeito Cascata:** O esgotamento desses recursos causou lentidão generalizada. Em resposta, o sistema tentou escalar automaticamente, o que abriu ainda mais conexões, limpando o cache de memória do banco e degradando a performance global. 4. **Configuração de Feature:** Uma funcionalidade ativada recentemente também realizava consultas sem índices, contribuindo para a carga excessiva. ## **Resolução** Para restaurar a estabilidade, a equipe técnica adotou as seguintes medidas: * **Suspensão da Migração:** O processo de importação de dados foi interrompido imediatamente para reduzir a carga. * **Desativação de Funcionalidade:** A configuração de consulta de selfies foi desabilitada globalmente, o que permitiu a recuperação imediata da performance do banco de dados. * **Troca de Réplica:** Tentou-se o redirecionamento do tráfego para diferentes instâncias de leitura para mitigar o gargalo. * **Hotfix:** Foi aplicado um ajuste emergencial no código para garantir que todas as consultas utilizassem obrigatoriamente os índices de partição corretos. ## **Lições Aprendidas** * **Visibilidade de Recursos:** Identificamos a necessidade de monitorar métricas específicas de exaustão de recursos de banco de dados \(como locks\) que não estavam em nosso monitoramento padrão. * **Validação de Índices:** Reforçamos a importância de garantir que novos endpoints ou processos de migração nunca realizem buscas em tabelas particionadas sem os filtros adequados. * **Gestão de Configurações:** Melhorar a correlação entre a ativação de funcionalidades \(flags\) e métricas de performance para reduzir o tempo de identificação de problemas \(MTTR\). Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 26, 2026, 06:45 PM UTC· resolved Jan 26, 2026, 08:43 PM UTC

1. identified Jan 26, 2026, 06:45 PM UTC

   Em investigação: Nossa equipe de monitoramento identificou um aumento de latência a com impacto em todas as capacidades IDcloud. Em breve voltamos com mais atualizações. Atenciosamente, Equipe Unico

2. identified Jan 26, 2026, 07:19 PM UTC

   Atualização do Incidente: Identificamos uma sobrecarga na camada de dados que está causando latência e erros intermitentes nas funcionalidades de detalhes dos processos. Como medida imediata, redirecionamos o tráfego para uma infraestrutura de banco de dados secundária e reiniciamos os serviços afetados. O sistema ainda apresenta sinais de instabilidade e nossa engenharia segue em análise de causas e medidas corretivas. Voltaremos em breve com atualizações.

3. monitoring Jan 26, 2026, 07:56 PM UTC

   Incidente sendo monitorado em fase de normalização Resumo e Impacto: Informamos que o acesso à visualização de detalhes de processos passou por uma breve instabilidade, resultando em respostas mais lentas do que o habitual para alguns usuários. Nossa equipe identificou o comportamento rapidamente e trabalhou para restabelecer a fluidez da plataforma. Desde as 16:15, o sistema opera com estabilidade e o desempenho já retornou aos padrões de normalidade, garantindo uma experiência de uso adequada a todos os nossos clientes. Causa e Resolução: A oscilação ocorreu devido à implementação de uma atualização que demandou um esforço de processamento acima do esperado em nossa base de dados. Como medida imediata, pausamos a nova função e ajustamos a distribuição de carga entre nossos servidores para aliviar o sistema. Com essas ações, a navegação foi normalizada. Seguimos monitorando o ambiente para assegurar a continuidade do serviço e a melhor performance em todas as funcionalidades.

4. resolved Jan 26, 2026, 08:43 PM UTC

   Resumo Executivo Pós Incidente Este incidente resultou em alta latência e erros intermitentes na funcionalidade de visualização de detalhes de processos, afetando a experiência de uso de uma parcela de nossos clientes. A instabilidade foi detectada via monitoramento automático, que apontou uma degradação severa na performance das consultas ao banco de dados. Durante o período de ocorrência entre 15h22 e 16h15, os usuários enfrentaram lentidão significativa ou falhas ao tentar acessar informações específicas em nossa plataforma, embora as demais funcionalidades tenham permanecido operacionais. Causa Raiz e Resolução: A investigação identificou que a causa raiz foi a ativação de uma nova configuração de funcionalidade (feature flag) para um cenário de alto volume de dados. Esta configuração acionou uma consulta ao banco de dados que não utilizava os filtros de partição adequados, forçando o sistema a realizar varreduras completas em todas as tabelas a cada requisição, o que sobrecarregou a memória das réplicas de leitura. A situação foi mitigada através do redirecionamento do tráfego para réplicas secundárias e, definitivamente, resolvida com a desativação da configuração ofensora. O serviço foi totalmente estabilizado e o desempenho das consultas normalizado após a correção da lógica de busca.

5. postmortem Jan 30, 2026, 11:58 AM UTC

   # Postmortem: Degradação de Performance nas Integrações ID ## **Resumo** No dia 26 de janeiro de 2026, entre **15:10 e 16:10**, nosso serviço de autenticação e processamento \(TCA\) apresentou degradação significativa, resultando em alta latência e erros de conexão para diversos clientes. O incidente foi desencadeado por uma saturação no pool de recursos do banco de dados, causada por consultas ineficientes durante um processo de migração de dados e agravada por uma configuração de funcionalidade específica. ## **Impacto** * **Duração:** 1 hora. * **Serviços Afetados:** O portal de gerenciamento e as APIs de consulta de detalhes de processos e selfies. * **Experiência do Usuário:** Clientes enfrentaram erros de timeout \(500\) e falhas na conclusão de jornadas que dependiam da visualização de dados de biometria. * **Escopo:** Inicialmente limitado a consultas específicas, o problema evoluiu para uma degradação generalizada de todas as jornadas do serviço devido ao esgotamento de conexões do banco de dados. ## **Causa Raiz** A causa raiz foi a **saturação de recursos no banco de dados**. ‌ 1. **Consultas Ineficientes:** Durante uma migração de dados, o volume de requisições aumentou, executando consultas em tabelas particionadas sem a identificação do índice de partição. 2. **Full Scans:** Sem o índice, o banco realizava varreduras completas em mais de 300 partições para cada busca, consumindo rapidamente o pool de "locks" disponíveis. 3. **Efeito Cascata:** O esgotamento desses recursos causou lentidão generalizada. Em resposta, o sistema tentou escalar automaticamente, o que abriu ainda mais conexões, limpando o cache de memória do banco e degradando a performance global. 4. **Configuração de Feature:** Uma funcionalidade ativada recentemente também realizava consultas sem índices, contribuindo para a carga excessiva. ## **Resolução** Para restaurar a estabilidade, a equipe técnica adotou as seguintes medidas: * **Suspensão da Migração:** O processo de importação de dados foi interrompido imediatamente para reduzir a carga. * **Desativação de Funcionalidade:** A configuração de consulta de selfies foi desabilitada globalmente, o que permitiu a recuperação imediata da performance do banco de dados. * **Troca de Réplica:** Tentou-se o redirecionamento do tráfego para diferentes instâncias de leitura para mitigar o gargalo. * **Hotfix:** Foi aplicado um ajuste emergencial no código para garantir que todas as consultas utilizassem obrigatoriamente os índices de partição corretos. ## **Lições Aprendidas** * **Visibilidade de Recursos:** Identificamos a necessidade de monitorar métricas específicas de exaustão de recursos de banco de dados \(como locks\) que não estavam em nosso monitoramento padrão. * **Validação de Índices:** Reforçamos a importância de garantir que novos endpoints ou processos de migração nunca realizem buscas em tabelas particionadas sem os filtros adequados. * **Gestão de Configurações:** Melhorar a correlação entre a ativação de funcionalidades \(flags\) e métricas de performance para reduzir o tempo de identificação de problemas \(MTTR\). ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 22, 2026, 12:08 AM UTC· resolved Jan 22, 2026, 12:08 AM UTC

1. investigating Jan 21, 2026, 11:51 PM UTC

   Identificamos uma degradação as 20h07 em nossa plataforma de mensageria, gerando falhas no fluxo de mensagens dos produtos ID Check, ID Unico, integração By Unico, IDPay, Unico People, Unico Auto, ID SIGN.

2. monitoring Jan 21, 2026, 11:52 PM UTC

   Os serviços de SMS e mensageria foram reestabelecidos. Nossa equipe segue acompanhando e monitorando os indicadores deste recurso. Agradecemos a compreensão e em breve retornaremos com mais informações

3. resolved Jan 22, 2026, 12:08 AM UTC

   Relatório de Incidente: Instabilidade no Serviço de Mensageria Resumo Executivo e Impacto: No dia 21 de janeiro de 2026, identificamos uma instabilidade que afetou o processamento de novas solicitações em nossa plataforma. Durante o período do incidente, aproximadamente 6% das requisições ao endpoint de criação de processos apresentaram falhas ou tempos de resposta elevados (timeouts). O impacto foi limitado a uma fração das operações de mensageria, não afetando a integridade dos dados armazenados ou outros serviços core da infraestrutura. Causa Raiz e Resolução: A investigação técnica determinou que o incidente foi causado pela saturação de memória na camada de cache (Redis), o que levou o serviço de gerenciamento de mensagens a um estado de reinicialização contínua (crash loop). Para normalizar a operação, a equipe de engenharia expandiu a capacidade de escalonamento automático do serviço, dobrando o número mínimo de instâncias ativas para garantir a disponibilidade sob carga. Após o redimensionamento e a reinicialização dos componentes afetados, o serviço foi restabelecido integralmente e a taxa de erro retornou aos níveis nominais. Reforçamos nosso compromisso com a transparência e permanecemos à disposição para quaisquer esclarecimentos adicionais por meio dos nossos canais oficiais de suporte. Atenciosamente, Equipe Unico.

4. postmortem Feb 06, 2026, 01:53 PM UTC

   # Postmortem: **Data do Incidente:** 21 de janeiro de 2026 **Duração do Impacto:** Aproximadamente 1 hora e 10 minutos ### Resumo Executivo Em 21 de janeiro de 2026, entre 19:25 e 20:30 \(horário de Brasília\), nossa plataforma enfrentou uma instabilidade no sistema de mensageria. O incidente resultou em latência elevada e falhas no envio de notificações transacionais \(SMS, E-mail e WhatsApp\). A equipe de engenharia identificou a causa raiz relacionada à saturação de recursos de infraestrutura devido a um pico de tráfego atípico e aplicou as correções necessárias para restabelecer o serviço. ### Impacto Durante o período do incidente, o serviço responsável pelo gerenciamento de mensagens ficou indisponível, afetando as seguintes operações: * **Envio de Notificações:** Falhas e atrasos significativos na entrega de mensagens críticas via SMS, E-mail e WhatsApp para os usuários finais. * **Jornadas do Cliente:** Fluxos de negócios que dependem dessas comunicações \(como validações de token ou confirmações de cadastro\) sofreram interrupções ou lentidão. * **Latência:** Observou-se um aumento expressivo no tempo de resposta das APIs de mensageria antes da interrupção total do serviço. ### Causa Raiz A investigação técnica determinou que a causa raiz foi a **saturação de memória no cluster de cache \(Redis\)** utilizado pelo sistema de mensageria. O incidente foi desencadeado pela execução de um processamento em lote \(_batch_\) de grande volume, que gerou uma demanda massiva e inesperada de requisições. O volume de dados excedeu a capacidade de memória provisionada \(5GB\) do banco de dados em memória, ativando mecanismos de proteção \(OOM Prevention\) que bloquearam novas escritas. Como consequência, os servidores da aplicação perderam a conexão com o cache e entraram em estado de falha \(_CrashLoopBackOff_\), tornando o serviço indisponível. ### Resolução e Recuperação A equipe de resposta a incidentes atuou nas seguintes frentes para mitigar e resolver o problema: 1. **Diagnóstico:** Identificação da falha de conexão e confirmação da saturação de memória no Redis. 2. **Escalonamento Horizontal:** Aumento imediato do número mínimo de réplicas \(pods\) do serviço de mensageria para lidar com a demanda represada. 3. **Escalonamento Vertical:** Aumento da capacidade de memória do cluster Redis de 5GB para 10GB, dobrando a disponibilidade de recursos. 4. **Estabilização:** Após a conclusão do escalonamento, o fluxo de mensagens foi normalizado e a latência retornou aos níveis operacionais padrões. ### Lições Aprendidas Para prevenir a recorrência deste cenário e aumentar a resiliência da plataforma, mapeamos os seguintes aprendizados: * **Melhoria na Observabilidade:** Implementação de alertas preventivos específicos para monitorar a saturação de recursos \(memória\) e a saúde dos componentes de cache, permitindo uma reação antes da indisponibilidade. * **Auto-scaling de Infraestrutura:** Revisão das políticas de infraestrutura para permitir o escalonamento automático de memória nos serviços de dados, adequando-se dinamicamente a picos de tráfego. * **Resiliência da Aplicação:** Adoção de padrões de _Graceful Degradation_ \(degradação graciosa\), garantindo que o sistema possa operar de forma limitada ou gerenciar falhas de dependências sem colapsar completamente

Read the full incident report →

Started Jan 19, 2026, 12:45 PM UTC· resolved Jan 19, 2026, 01:36 PM UTC

1. identified Jan 19, 2026, 01:30 PM UTC

   Prezado Cliente, Identificamos uma instabilidade nas requisições do produto IDPay, gerando instabilidade momentânea na criação de transações. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. A instabilidade ocorreu entre 09:45 e 10:10(BRT) Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

2. monitoring Jan 19, 2026, 01:34 PM UTC

   Prezado Cliente, Incidente resolvido. Identificamos uma instabilidade nas requisições do produto IDPay, gerando instabilidade momentânea na criação de transações. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. A instabilidade ocorreu entre 09:45 e 10:10(BRT) Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

3. resolved Jan 19, 2026, 01:36 PM UTC

   Relatório Pós-Incidente: Instabilidade nos Serviços do IDPAY Resumo Executivo e Impacto: No dia 19 de janeiro de 2026, entre 09:45 e 10:10 BRT, o serviço IDPAY apresentou uma degradação crítica em sua disponibilidade, afetando APIs fundamentais de transação, definições de retenção (holds) e validações de processos. Durante este intervalo de 25 minutos, a conformidade com os níveis de serviço (SLO) caiu para 76,5%, resultando em uma interrupção sustentada que impediu o processamento de requisições enviadas pelos parceiros. O incidente foi detectado via alertas automáticos assim que o volume de erros ultrapassou as margens de segurança estabelecidas para a operação. Causa Raiz e Resolução: A instabilidade foi causada por uma falha estrutural ocorrida durante a execução de uma migração de banco de dados, parte de uma atualização de versão do sistema. A alteração gerou inconsistências imediatas no processamento das APIs do IDPAY, elevando drasticamente a taxa de erros. A resolução foi concluída às 10:10 após a equipe técnica realizar a reversão manual da migração diretamente na camada de dados. Com o restabelecimento da configuração estável anterior, o serviço retornou à normalidade e a taxa de sucesso das transações foi totalmente recuperada. Agradecemos a compreensão e a parceria durante a resolução deste incidente. Nossa prioridade absoluta é garantir a resiliência e a estabilidade do IDPAY, e já estamos trabalhando no aprimoramento dos nossos processos de validação de infraestrutura para evitar que falhas em migrações voltem a impactar a sua operação. Reforçamos nosso compromisso com a transparência e permanecemos à disposição para quaisquer esclarecimentos adicionais por meio dos nossos canais oficiais de suporte. Atenciosamente, Equipe Unico

4. postmortem Jan 27, 2026, 12:47 PM UTC

   # Postmortem: Instabilidade nos Serviços do IDPAY ‌ ## Resumo No dia 19 de janeiro de 2026, entre 09:45 e 10:10 \(Horário de Brasília\), nossos serviços de processamento de pagamentos e validação de transações apresentaram uma degradação significativa. O incidente foi causado por uma alteração no esquema do banco de dados que gerou uma incompatibilidade com a versão do código em execução no ambiente de produção. A estabilidade foi restabelecida após a reversão manual das alterações no banco de dados. ‌ ## Impacto Durante o período de 25 minutos do incidente, a disponibilidade dos serviços caiu para **76,5%**. Os usuários enfrentaram erros intermitentes e falhas ao tentar criar ou validar transações e acessar funções de carteira. No pico da instabilidade, a taxa de erro chegou a aproximadamente **98%** para as APIs afetadas. ‌ ## Causa Raiz A falha foi originada por uma atualização de banco de dados em uma tabela crítica de configuração. Embora a migração e o novo código da aplicação tenham sido testados com sucesso em ambientes de homologação, houve uma divergência no tempo de execução entre o banco de dados e a implantação do código em produção. ‌ Isso criou uma "janela de incompatibilidade" onde o banco de dados já esperava uma estrutura nova, mas o serviço ainda operava com a lógica anterior. A ausência de um mecanismo de rollback automatizado para o banco de dados estendeu o tempo de recuperação, pois exigiu intervenção manual dos engenheiros. ‌ ## Resolução O incidente foi identificado às 09:56 após alertas de monitoramento. Após o diagnóstico da incompatibilidade, a equipe técnica realizou uma reversão manual dos procedimentos de migração diretamente no banco de dados. O serviço foi totalmente restaurado às 10:10, seguido por um período de monitoramento para garantir a estabilização das taxas de erro. ‌ ## Lições Aprendidas * **Estratégias de Migração Segura:** Mudanças em tabelas críticas devem adotar padrões de "expansão e contração", onde novas colunas são adicionadas sem remover as antigas imediatamente, garantindo compatibilidade com versões anteriores do código. * **Paridade de Ambientes:** É essencial que o sequenciamento e o tempo de implantação em ambientes de teste repliquem exatamente o comportamento do ambiente de produção para capturar condições de corrida e incompatibilidades temporais. * **Automação de Rollback:** Processos manuais em momentos de crise aumentam o tempo médio de recuperação \(MTTR\) e o risco de erro humano. A automação da reversão de esquemas de banco de dados é uma prioridade para serviços críticos. * **Monitoramento em Tempo Real:** A presença de uma política de acompanhamento em dupla durante implantações críticas permite uma detecção e resposta mais ágil a anomalias. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 13, 2026, 01:03 PM UTC· resolved Jan 13, 2026, 02:35 PM UTC

1. investigating Jan 13, 2026, 01:03 PM UTC

   Prezado Cliente, Identificamos uma instabilidade no Portal B2B, gerando impacto no fluxo de geração de relatórios e Dashboard de métricas para ByUnico e ByClient. Nosso time de tecnologia está trabalhando para identificar e resolver o problema.

2. identified Jan 13, 2026, 01:17 PM UTC

   Prezado Cliente, Identificamos a causa do problema no PortalB2B, onde está gerando impacto no fluxo de geração de relatórios e Dashboard de métricas para ByUnico e ByClient. Nossa equipe de tecnologia está atuando para solução desde incidente. Em breve traremos atualizações.

3. monitoring Jan 13, 2026, 02:16 PM UTC

   Prezado Cliente, A execução das ações necessárias foi concluída com sucesso, restabelecendo o ambiente. Neste instante as funcionalidades do PortalB2B está operando adequadamente. Estamos iniciando a fase de operação assistida e monitorando a performance do ambiente.

4. resolved Jan 13, 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. Causa raiz e Resolução: Havia uma checagem de permissionamento que estava bloqueando os usuários de acessaram a exportação de dados e o dashboard do PortalB2B. Essa checagem faz o switch da visão byUnico e byClient dentro da camada semântica do Looker. Após a subida de uma nova versão do nosso time de engenharia, o sistema voltou a operar normalmente conforme o esperado. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

5. postmortem Jan 23, 2026, 07:43 PM UTC

   # Postmortem: Instabilidade PortalB2B - Geração de relatórios e Dashboard de métricas ### Resumo Entre as 09:00 e as 23:00 \(BRT\) de 13 de janeiro de 2026, os usuários do PortalB2B enfrentaram uma indisponibilidade total no módulo de relatórios e nas funcionalidades de exportação de dados. O incidente foi provocado por uma falha de software introduzida em uma atualização de backend realizada no dia anterior, que comprometeu a lógica de permissões de acesso. O serviço foi restabelecido após a correção da lógica de validação na camada de integração com a ferramenta de visualização de dados. ‌ ## Impacto O incidente afetou 100% dos usuários que utilizam o módulo de relatórios e exportação de dados do PortalB2B. Durante o período de impacto, os clientes não conseguiram visualizar dashboards ou extrair informações, recebendo mensagens de erro de carregamento \(HTTP 404\) dentro da interface do portal. Outras funcionalidades do portal, como a visualização de processos, permaneceram operacionais e não foram afetadas. ‌ ## Causa Raiz A falha foi originada por uma atualização de software em um serviço de backend. Esta atualização introduziu um erro no processamento dos dados de permissão, fazendo com que o sistema enviasse valores padrão \(_default_\) em vez das credenciais de acesso corretas dos usuários para a plataforma de relatórios. ‌ Essa inconsistência quebrou a lógica de segurança na camada semântica, resultando no bloqueio sistemático de todos os acessos. A detecção automática foi dificultada pela arquitetura de integração, que mascarou os erros nas métricas tradicionais de monitoramento de backend. ‌ ## Resolução Após a identificação de que o erro 404 era causado por uma falha de permissão e não por uma instabilidade na infraestrutura de nuvem, a equipe de engenharia desenvolveu uma correção para a lógica de validação. O restabelecimento do serviço ocorreu através de uma instalação de uma nova versão das extensões da ferramenta de visualização, corrigindo a validação de permissões e restaurando o acesso normal aos usuários. ‌ ## Lições Aprendidas * **Validação de Integrações Críticas:** Alterações em serviços de backend que fornecem dados para sistemas terceiros exigem ambientes de homologação que repliquem fielmente a integração completa. * **Visibilidade do Serviço:** É necessário monitorar não apenas se os servidores estão ligados, mas se o conteúdo está sendo exibido corretamente dentro do portal. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 13, 2026, 09:15 AM UTC· resolved Jan 13, 2026, 10:15 AM UTC

1. monitoring Jan 13, 2026, 12:15 PM UTC

   Prezado Cliente, Instabilidade Resumo Executivo e Impacto: No dia 13 de janeiro de 2026, entre 06:15 e 07:08 BRT, identificamos uma violação nas taxas de disponibilidade afetando a hospedagem de ativos (assets) do nosso SDK Web. Durante este período de 53 minutos, usuários finais podem ter enfrentado dificuldades ou falhas no carregamento de componentes críticos, como arquivos JavaScript e módulos WASM, essenciais para o funcionamento das ferramentas de captura em navegadores. O impacto manifestou-se através de erros de servidor (HTTP 500) e uma taxa elevada de falhas nas validações de prova de vida (liveness), afetando a estabilidade da experiência de integração em diversos parceiros. Causa Raiz e Resolução: A instabilidade foi desencadeada pela implantação de uma nova versão do SDK Web iniciada às 06:15. Após a publicação, foram detectadas inconsistências na nova versão que impediam o fornecimento correto dos ativos hospedados. Assim que a anomalia foi confirmada por meio de monitoramento automático, a equipe técnica iniciou os protocolos de resposta, optando pela reversão imediata (rollback) para a versão estável anterior. A resolução foi concluída às 07:08, restabelecendo a disponibilidade total dos serviços e a normalização das taxas de sucesso de carregamento. Pedimos desculpas pelo inconveniente, e estamos trabalhando com ações de melhoria contínua para evitar eventos como este no futuro. Atenciosamente, Equipe Unico.

2. resolved Jan 13, 2026, 12:16 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. Atenciosamente, Equipe Unico!

3. postmortem Feb 13, 2026, 08:57 PM UTC

   **Postmortem: Indisponibilidade na Hospedagem de Assets do Web SDK** **Data do Incidente:** 13 de Janeiro de 2026 **Status:** Resolvido **Resumo Executivo:** Em 13 de janeiro de 2026, entre 06:15 e 07:08 \(horário local\), nossa plataforma enfrentou um incidente que impactou a disponibilidade dos assets do nosso Web SDK. O problema resultou de uma falha nas políticas de permissão de acesso \(CORS\) durante a implantação de uma nova versão do produto. A normalidade do serviço foi totalmente restaurada após revertermos a atualização para a versão estável anterior. **Impacto** Durante a janela de instabilidade de 53 minutos, os parceiros integrados à nossa solução de Web SDK enfrentaram degradação em seus fluxos. * Ocorreram erros de servidor, com retornos de status HTTP 500 nas tentativas de uso do SDK. * Houve uma taxa elevada de falhas durante as validações biométricas de prova de vida \(liveness\). **Causa Raiz** A instabilidade foi gerada por um problema de configuração de compartilhamento de recursos \(Cross-Origin Resource Sharing - CORS\) ausente no ambiente de produção para a nova versão implantada do SDK. Durante o ciclo de vida de uma versão anterior, os requisitos de CORS haviam sido configurados de uma forma diferente e manual diretamente no ambiente, sem que o histórico dessas permissões fosse devidamente salvo em nosso sistema de controle de versão de código. Consequentemente, ao realizarmos o deployment da nova versão, a plataforma presumiu que as configurações estavam íntegras. Como as regras corretas não foram herdadas pelos novos arquivos, os navegadores dos usuários finais bloquearam o acesso aos recursos críticos, resultando na indisponibilidade. **Resolução e Mitigação** Assim que a anomalia foi detectada durante as validações do novo deplo_yment_, nossa equipe de engenharia iniciou imediatamente o protocolo de contenção. * Foi executado um roll_back_ ágil para reverter o sistema para a última versão estável conhecida, eliminando o impacto aos parceiros e clientes finais. * Posteriormente, iniciamos a codificação e o dep_loyment_ das regras de CORS definitivas no código-fonte, garantindo que o problema fosse resolvido antes de novas atualizações. **Ações Preventivas e Lições Aprendidas** Para blindar nossa operação e evitar cenários semelhantes no futuro, documentamos e reforçamos os seguintes aprendizados práticos: **Infraestrutura como Código Estrita:** Todas as alterações de ambiente e configurações \(como regras de CORS\) devem ser executadas e registradas unicamente via controle de versão. A aplicação manual de configurações no passado gerou uma "falsa segurança", mascarando um débito técnico que afetou um de_ployment_ futuro. **Cultura de Rollback Imediato:** O incidente provou a eficácia da nossa diretriz de mitigação imediata. A prática de executar um _rollback_ instantâneo ao primeiro sinal de degradação após uma implantação continuará sendo o padrão de ouro para priorizar a disponibilidade das operações de nossos parceiros. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas

Read the full incident report →

Started Jan 13, 2026, 04:27 AM UTC· resolved Jan 14, 2026, 05:57 AM UTC

1. monitoring Jan 14, 2026, 02:46 PM UTC

   Relatório Pós-Incidente: Mitigação de Vulnerabilidade de Segurança em Serviço de Mensagens Resumo Executivo e Impacto: No dia 14 de janeiro de 2026, entre 01:27 e 02:57 BRT, nossos sistemas de monitoramento identificaram um volume de tráfego anômalo direcionado ao serviço de captura de mensagens. Como medida de proteção proativa, nossos mecanismos de defesa automatizados foram acionados para mitigar a atividade suspeita. Durante a atuação das contramedidas de segurança, alguns fluxos legítimos de validação podem ter enfrentado intermitência ou latência até a normalização completa do ambiente. Causa Raiz e Resolução: A instabilidade foi causada por uma tentativa externa de exploração de padrões de requisição, o que elevou drasticamente a carga no endpoint. Nossas equipes de Engenharia e Segurança atuaram prontamente ajustando as regras do WAF (Web Application Firewall) para filtrar o tráfego malicioso. O incidente foi contido com sucesso, o tráfego ilegítimo foi bloqueado e a operação do serviço foi totalmente restabelecida. Continuamos monitorando o ambiente com prioridade elevada para garantir a disponibilidade e a segurança de nossos clientes. Agradecemos a compreensão. Equipe Unico.

2. resolved Jan 14, 2026, 02:47 PM UTC

   Relatório Pós-Incidente: Mitigação de Vulnerabilidade de Segurança em Serviço de Mensagens Resumo Executivo e Impacto: No dia 14 de janeiro de 2026, entre 01:27 e 02:57 BRT, nossos sistemas de monitoramento identificaram um volume de tráfego anômalo direcionado ao serviço de captura de mensagens. Como medida de proteção proativa, nossos mecanismos de defesa automatizados foram acionados para mitigar a atividade suspeita. Durante a atuação das contramedidas de segurança, alguns fluxos legítimos de validação podem ter enfrentado intermitência ou latência até a normalização completa do ambiente. Causa Raiz e Resolução: A instabilidade foi causada por uma tentativa externa de exploração de padrões de requisição, o que elevou drasticamente a carga no endpoint. Nossas equipes de Engenharia e Segurança atuaram prontamente ajustando as regras do WAF (Web Application Firewall) para filtrar o tráfego malicioso. O incidente foi contido com sucesso, o tráfego ilegítimo foi bloqueado e a operação do serviço foi totalmente restabelecida. Continuamos monitorando o ambiente com prioridade elevada para garantir a disponibilidade e a segurança de nossos clientes. Agradecemos a compreensão. Equipe Unico.

3. postmortem Jan 27, 2026, 06:28 PM UTC

   # Postmortem: Instabilidade do fluxo de Mensagens ## Resumo No dia 14 de janeiro de 2026, identificamos uma instabilidade no endpoint de captura de mensagens, resultando em erros intermitentes para usuários em processo de onboarding. O incidente foi desencadeado por uma carga excessiva de requisições de teste originadas de uma plataforma de segurança externa, que explorou vulnerabilidades de entrada em componentes legados. A situação foi normalizada através do bloqueio do tráfego anômalo na camada de borda e ajuste das regras de segurança. ‌ ## Impacto * **Duração:** O incidente teve impacto direto por aproximadamente 43 minutos. * **Serviços Afetados:** Fluxo de captura de SMS e Onboarding de clientes. * **Experiência do Usuário:** Aproximadamente 100% das requisições direcionadas ao endpoint específico apresentaram erro HTTP 500 durante a janela de maior instabilidade. ## Causa Raiz A instabilidade foi causada por um ataque de **fuzzing/XSS** que visava identificar falhas de segurança. O sistema não estava devidamente preparado para esse volume de requisições agressivas nos componentes legados, que careciam de uma sanitização de inputs robusta no lado da aplicação. ‌ Além disso, identificamos que as proteções de borda \(WAF\) para esses subdomínios específicos estavam configuradas apenas em modo de monitoramento \("Preview"\), não bloqueando as ameaças automaticamente antes que atingissem a infraestrutura interna. ‌ ## Resolução Assim que a detecção automática disparou os alertas, as seguintes medidas foram tomadas: 1. **Identificação da Origem:** A equipe técnica identificou o endereço IP responsável pelo volume anômalo de tráfego. 2. **Bloqueio de Borda:** Foi efetuado o bloqueio manual do tráfego ofensivo na camada de firewall de aplicação \(WAF\). 3. **Ajuste de Regras:** Novas regras de segurança foram habilitadas e validadas para garantir que variações do mesmo ataque fossem mitigadas em tempo real. 4. **Monitoramento:** O serviço foi monitorado até a total estabilização, sem novos erros registrados após a intervenção. ## Lições Aprendidas * **Defesa em Profundidade:** A dependência exclusiva de proteções em modo de monitoramento em ambientes de produção pode expor componentes sensíveis a picos de tráfego malicioso. * **Gestão de Legados:** Sistemas mais antigos exigem atenção redobrada quanto à sanitização de dados, especialmente quando expostos a programas de testes públicos. * **Sincronia de Segurança:** A abertura de programas de segurança externa deve estar rigorosamente alinhada com a maturidade das regras de bloqueio de borda em todo o perímetro da aplicação. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 12, 2026, 06:39 PM UTC· resolved Jan 12, 2026, 07:38 PM UTC

1. investigating Jan 12, 2026, 06:39 PM UTC

   Prezados clientes, Identificamos uma instabilidade na plataforma Unico People-Sign, que está afetando o envio de novos envelopes. Nossa equipe de engenharia já está ciente e trabalhando com máxima urgência para identificar a causa raiz e aplicar a correção necessária. Manteremos vocês informados sobre qualquer atualização ou previsão de normalização. Pedimos desculpas pelo inconveniente e agradecemos a compreensão. Atenciosamente,

2. resolved Jan 12, 2026, 07:38 PM UTC

   Prezados clientes, Informamos que a instabilidade no Unico People-Sign, que afetava o envio de novos envelopes, foi resolvida. Nossa equipe de engenharia identificou a causa do problema e aplicou a correção necessária, normalizando o serviço integralmente. O ambiente já se encontra estável e operacional. Agradecemos a paciência e compreensão durante o ocorrido. Atenciosamente,

Read the full incident report →

Started Jan 08, 2026, 05:00 PM UTC· resolved Jan 08, 2026, 05:00 PM UTC

1. resolved Jan 08, 2026, 05:48 PM UTC

   Prezado Cliente, Identificamos uma instabilidade nas requisições do produto Alerta de Comportamento (ID Trust) nas operações localizadas no Mexico, gerando aumento no tempo de resposta ou erros nas requisições. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. A instabilidade ocorreu entre 14:13 e 14:27(BRT) Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

2. postmortem Jan 19, 2026, 05:32 PM UTC

   # Postmortem: Instabilidade no Serviço de Alerta de comportamento ID Trust afetando clientes do Mexico ### Resumo No dia 8 de janeiro de 2026, identificamos uma instabilidade temporária que afetou a disponibilidade de nossos serviços de avaliação de risco para operações no México. O incidente foi causado por uma falha em uma dependência externa, resultando em erros de resposta e picos de latência durante um curto intervalo de tempo. ‌ ### Impacto O incidente teve uma duração total de **14 minutos**, entre **14:13 e 14:27** \(horário local\). Durante este período: ‌ * Aproximadamente 1.300 requisições de clientes falharam ou não receberam resposta. * O impacto foi observado de forma generalizada nas integrações que dependem do serviço de predição. ### Causa Raiz A instabilidade foi originada por uma falha de hardware na infraestrutura de um provedor de nuvem que sustenta um de nossos parceiros de serviço. Especificamente, ocorreu uma degradação no serviço de banco de dados em memória devido a um problema no host físico subjacente, o que disparou um processo automático de recuperação de nó. Durante esse processo de transição, o serviço apresentou indisponibilidade pontual e latência elevada. ‌ ### Resolução O serviço foi restabelecido automaticamente assim que o provedor de nuvem concluiu a substituição do nó afetado e a recuperação da infraestrutura de rede. Não foi necessária uma intervenção manual direta em nossos sistemas para a normalização das operações, que voltaram ao estado estável às 14:27. ‌ ### Lições Aprendidas Este evento reforçou a importância da resiliência em camadas diante de falhas de terceiros. As principais conclusões foram: * **Aprimoramento de Mitigação:** Identificamos a necessidade de ajustar os tempos de resposta para garantir que falhas externas não se propaguem de forma agressiva para o usuário final. * **Resiliência de Integração:** Revisamos a forma como tratamos erros de dependências críticas para garantir que, mesmo em casos de instabilidade externa, o sistema possa falhar de forma controlada ou oferecer respostas alternativas quando possível. * **Alta Disponibilidade:** A importância da configuração Multi-AZ para serviços críticos de infraestrutura para minimizar o tempo de inatividade durante falhas de hardware. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Read the full incident report →

Started Jan 06, 2026, 03:38 PM UTC· resolved Jan 06, 2026, 04:00 PM UTC

1. investigating Jan 06, 2026, 03:38 PM UTC

   Prezado Cliente, Identificamos uma instabilidade que afeta as chamadas de nossa SDK, com impacto direto nos produtos que usam a capacidade de Prova de Vida. Nossa equipe de engenharia já está atuando na investigação da causa raiz para restabelecer a normalidade o quanto antes. Manteremos você informado sobre a evolução da correção através desta página. Atenciosamente, Equipe Unico

2. monitoring Jan 06, 2026, 03:48 PM UTC

   Prezado Cliente, Informamos que a causa da instabilidade na SDK e na Prova de Vida foi identificada e a correção já foi implementada. Neste momento, nossos serviços operam com estabilidade. Permaneceremos monitorando as métricas de performance e o comportamento do ambiente por um período adicional para garantir a total normalização. Atenciosamente, Equipe Unico

3. resolved Jan 06, 2026, 04:00 PM UTC

   Prezado Cliente, Informamos que o incidente que afetava a nossa SDK e o serviço de Prova de Vida foi totalmente resolvido. Após um período de monitoramento sem novas ocorrências, confirmamos que todos os serviços estão operando dentro da normalidade. Lamentamos qualquer transtorno causado e agradecemos a sua compreensão. Atenciosamente, Equipe Unico

4. postmortem Jan 12, 2026, 01:29 PM UTC

   # Postmortem: Instabilidade na SDK e Prova de Vida ## Resumo No dia **06 de janeiro de 2026**, entre **12:04 e 12:50** \(horário de Brasília\), experimentamos uma interrupção total nos serviços de captura de dados e biometria via SDK. O incidente foi desencadeado por uma alteração nas configurações de roteamento de rede durante uma atualização planejada para implementar redundância geográfica \(multi-região\). A falha foi corrigida através da reversão da configuração de rede, restaurando a normalidade em 46 minutos. ‌ ## Impacto O incidente teve um impacto de **100% de erro** nas requisições de biometria durante o período de interrupção. ‌ * **Serviços Afetados:** Captura de dados e processamento de biometria facial \(Liveness\). * **Experiência do Usuário:** Clientes e usuários finais enfrentaram falhas críticas ao tentar realizar autenticações biométricas, resultando em erros de conexão e indisponibilidade de serviço. ## Causa Raiz A investigação técnica identificou que a causa raiz foi uma **interferência na precedência de rotas** dentro do nosso orquestrador de tráfego. ‌ Durante o processo de automação para suporte multi-região, foi introduzida uma nova rota genérica nomeada como "default". Devido ao funcionamento do motor de templates utilizado em nossa esteira de implantação, as rotas foram ordenadas alfabeticamente no manifesto final. Como a palavra "default" precede alfabeticamente as rotas específicas de biometria, ela passou a interceptar todo o tráfego antes que as regras corretas pudessem ser processadas. Por não possuir critérios de filtragem específicos, essa nova rota direcionou o tráfego incorretamente, causando erros de processamento. ‌ ## Resolução A recuperação do serviço seguiu o cronograma abaixo: * **12:11:** Primeiro alerta automático disparado pelo sistema de monitoramento. * **12:17:** Detecção oficial e início da mobilização do time de engenharia. * **12:21:** Identificação de que a falha estava ligada ao deployment recente de rede. * **12:47:** Implementação da **correção definitiva** com a remoção da configuração de rota conflitante. * **12:50:** Restauração completa de todos os serviços e início do período de monitoramento de estabilidade. ## Lições Aprendidas O incidente trouxe aprendizados valiosos para aprimorar a resiliência de nossa infraestrutura: * **Ordenação de Tráfego:** Identificamos a necessidade de implementar controles que garantam a ordem explícita de processamento de rotas, evitando que a ordenação automática por nome cause efeitos colaterais. * **Validação de Manifestos:** Verificamos uma oportunidade de melhoria em nossos processos de integração contínua para incluir a análise de diferenças de configurações de infraestrutura antes da aplicação em produção. * **Precedência de Regras:** Reforçamos a importância de testes de roteamento que validem não apenas a nova funcionalidade, mas se a precedência das regras existentes permanece íntegra após atualizações de rede. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas. ‌ Atenciosamente, Equipe Unico.

Read the full incident report →