73 Socure incidents · Gwengolo 2025 — official updates, affected components, duration and resolution details.
Em 27 de outubro de 2026, alguns clientes foram incapazes de receber riskOS Sandbox webhooks. O problema foi causado por configurações webhook inválidas que fizeram com que o remetente de notificação Sandbox parasse de processar eventos. As configurações malformadas foram corrigidas. Todo o processamento recuperou e entrega webhook foi retomada com sucesso
Traduzido automaticamente da atualização oficial do incidente.
A SSA está atualmente experimentando um evento de impacto de serviço que afeta vários aplicativos e serviços, incluindo o serviço de Verificação de Número de Segurança Social Baseada em Consentimento Eletrônico (eCBSV). Um pequeno número de transacções é afectado, uma vez que a perturbação foi observada pela primeira vez em aproximadamente 4:47 PM (ET) em 23 de Outubro de 2026. Vamos compartilhar outra atualização quando recebermos o aviso de que o serviço foi restaurado, e o eCBSV está operando normalmente novamente.
Aproximadamente às 4:56 (ET), o serviço foi restaurado e o eCBSV está operando normalmente neste momento. Pedimos desculpa por qualquer inconveniente que isto possa ter causado.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos investigando um problema que está causando latência intermitente com exibição e download de Imagens DocV para uma pequena porcentagem de transações concluídas. Não há impacto no DocV nem avaliações neste momento, mas as imagens podem levar mais tempo para aparecer.
Nossa equipe tomou medidas para mitigar a latência vivenciada para exibição de imagem DocV e downloads. Continua a não haver impacto nas avaliações do DocV neste momento e a equipa continuará a acompanhar a situação. Forneceremos outra atualização quando todo o impacto tiver sido resolvido.
Esta questão foi resolvida, e estamos monitorando o desempenho para garantir que os serviços permaneçam estáveis. Pedimos desculpa por qualquer inconveniente que isto possa ter causado.
Traduzido automaticamente da atualização oficial do incidente.
A SSA experimentou um evento de impacto de serviços que afetou várias aplicações e serviços, incluindo o serviço de Verificação de Número de Segurança Social Baseada em Consentimento Eletrônico (eCBSV). Um pequeno número de transações foi afetado como a interrupção começou em aproximadamente 2:50PM (ET) em 18 de outubro de 2026, e foi resolvido em aproximadamente 3:10PM (ET). O serviço foi restaurado, e o eCBSV está operando normalmente neste momento.
Traduzido automaticamente da atualização oficial do incidente.
A partir das 3:00 EDT, alguns clientes podem experimentar erros intermitentes ou solicitações falhadas ao usar as APIs de avaliação do RiskOS. Identificamos um problema de banco de dados e estamos trabalhando ativamente para resolvê-lo. Pedimos desculpas pela interrupção e apreciamos a sua paciência enquanto investigamos.
Tomamos uma medida provisória, e a taxa de erro elevada diminuiu. Não observamos erros relacionados nos últimos 15 minutos. Estamos movendo o incidente para o monitoramento enquanto continuamos trabalhando em uma resolução completa. Vamos compartilhar outra atualização quando a situação mudar.
Agradecemos sua paciência, pois nossa equipe ainda está monitorando a situação de perto. As taxas de erro diminuíram à medida que continuamos a trabalhar para uma resolução completa.
O incidente foi resolvido e já não vemos erros. Os serviços estão funcionando normalmente, e continuaremos monitorando o desempenho. Agradecemos a vossa paciência enquanto trabalhámos.
Traduzido automaticamente da atualização oficial do incidente.
Os serviços Socure RiskOS e ID+ foram restaurados. Um erro em uma implantação causou um pico temporário nas taxas de erro de nossos serviços entre 18:12 e 18:56 horário oriental. O erro foi corrigido e os serviços estão estáveis agora. Entendemos que esta interrupção é inaceitável e que uma ACR completa estará disponível assim que a análise completa da questão estiver concluída.
# # ** Análise de Causas Root # **Incidente: ** Falta de APIs de socure **Data:** 15-Oct-2026 **Impacto:** Interrupção em serviço para APIs do Socure ** Status: ** Resolvido ### **1. Resumo** Em 15-out-2026, entre 18:12 e 19:00 horário oriental Socure experimentou uma interrupção em seus RiskOS e ID\+ APIs, causando erros e timeouts para os usuários. A primeira fase correu de 18:12 a 18:20, e foi uma grande interrupção para praticamente todos os serviços. A segunda fase da parada correu de 18:20 a 19:00, e foi uma parada parcial para serviços que dependem de dados KYC, onde os clientes viram elevadas taxas de erro e latências para alguns serviços, mas o tráfego ainda estava sendo servido. Tradução: ** Data / Hora \(ET\)** . **18:12** Uma mudança de limpeza de rotina é mesclada, movendo um repo fonte de um repositório de código para outro. Um bug em nossa ferramenta de revisão esconde o escopo da mudança. **18:13** ArgoCD reinicia a maioria dos serviços em um grande cluster Kubernetes ao mesmo tempo. **18:20** Todos os pods de serviço estão em execução. Serviço parcial de API restaurado, embora os serviços KYC ainda estejam vendo uma taxa de erro elevada. **18:21** A inundação de tráfego de inicialização sobrecarrega nosso serviço de pesquisa KYC. As taxas de erro aumentam. **18:42** O SRE diagnostica a falha da cascata que afeta o KYC Search e bloqueia o tráfego para que possa vir acima. **18:56** O serviço de pesquisa KYC está totalmente acima, e SRE retorna tráfego para ele. Os serviços a jusante estabilizam. **19:00** .. Todo o tráfego em funcionamento como normal, incidente declarado estável. # # # **3. Causa raiz # * ** Causa Primária:** Como parte de uma migração contínua, um SRE de plantão fez uma mudança para ArgoCD, o sistema que usamos para gerenciar os clusters Kubernetes A Socure executa seus serviços. A mudança foi dimensionada para um único cluster, foi revisada cuidadosamente antes de empurrar, não causou problemas em outros ambientes em que foi testado, e não deveria ter tido impacto visível. Infelizmente, a mudança atualizou uma configuração do legado que não apareceu na revisão da mudança. Essa configuração legada governava quais serviços a ArgoCD gerenciava e removeu muitos serviços ao vivo da ArgoCD. Em consequência, a ArgoCD retirou brevemente esses serviços da produção, antes de a configuração ser corrigida. * ** Fatores Contribuintes: ** O serviço de pesquisa KYC é uma peça de infraestrutura da Socure que fornece serviços para vários dos nossos produtos internos. Quando esse serviço foi reiniciado do zero ao mesmo tempo que todos os clientes do serviço, um pequeno número de pods no serviço caiu sob carga. Isso aumentou a carga nas cápsulas restantes, algumas das quais caíram por sua vez. Este fracasso em cascata impediu o serviço de voltar por conta própria, como fez o resto da infraestrutura da Socure. O diagnóstico desse modo de falha separado levou mais tempo, e remediando os erros restantes após o incidente inicial. # # # **4. Resolução # A mudança do ArgoCD foi revertida imediatamente, fazendo com que os serviços retornassem ao seu estado anterior. O serviço de pesquisa KYC exigiu esforço manual para bloquear o tráfego de alcançá-lo até que a maioria dos pods no serviço pudesse surgir. Depois que o serviço era saudável, nós poderíamos restaurar o tráfego para ele e resolver o incidente geral. ### **5. Ações corretivas e preventivas# 6. Lições aprendidas * A ferramenta da Socure para visualizar as mudanças que ela faz na produção não funcionou corretamente. Estamos revisando essas ferramentas para garantir que elas funcionem corretamente em todos os casos de uso e corrigir casos como este onde o escopo completo de uma mudança não é claro. * Aumente o processo de revisão de mudanças existente com suporte a agentes. Embora neste caso, a mudança específica não tenha sido visível no plano, ter um revisor suplementar que seja apoiado por um modelo de treinamento extenso ajudará a garantir que as questões sejam captadas antes da submissão. * Mesmo as mudanças que parecem não ter impacto, quando elas são feitas para o sistema de governança para os nossos empregos de produção, pode ser arriscado, e deve ser deslocado mais fora do horário comercial dos EUA. * O nosso serviço de pesquisa KYC é vulnerável a um problema de "troca-herdeiro" quando recebe fluxo de tráfego total quando não está totalmente online. Precisamos fortalecer nossos disjuntores para evitar que esta questão se repita. * Executamos muitos dos nossos principais serviços API em um único cluster kubernetes. Mesmo que esse cluster seja distribuído em várias zonas de disponibilidade, o plano de controle compartilhado cria um raio de explosão muito alto para mudanças nesse cluster. Próximos passos e compromisso contínuo A Socure entende que nossos clientes dependem de nós como um provedor chave em fluxos de negócios críticos, e que essa interrupção de serviço não é aceitável. Pedimos desculpa pelo impacto que esta questão causou e comprometemo-nos a garantir que ela não se repita. Para esse fim, forneceremos detalhes sobre nossos planos de re-arquitetar nosso layout de aplicação até novembro, bem como melhoraremos a resiliência do serviço de pesquisa KYC no Q1 do próximo ano.
Traduzido automaticamente da atualização oficial do incidente.
Os serviços Socure RiskOS e ID+ foram restaurados. Um erro em uma implantação causou um pico temporário nas taxas de erro de nossos serviços entre 18:12 e 18:56 horário oriental. O erro foi corrigido e os serviços estão estáveis agora. Entendemos que esta interrupção é inaceitável e que uma ACR completa estará disponível assim que a análise completa da questão estiver concluída.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos passando por um incidente ativo que está impactando a disponibilidade do serviço. Estamos atualmente investigando o problema e forneceremos atualizações assim que tivermos informações adicionais.
Os serviços Socure RiskOS e ID+ foram restaurados. Um erro em uma implantação causou um pico temporário nas taxas de erro de nossos serviços entre 18:20 e 18:56 horário oriental. O erro foi corrigido e os serviços estão estáveis agora. Entendemos que esta interrupção é inaceitável e que uma ACR completa estará disponível assim que a análise completa da questão estiver concluída.
Os serviços Socure RiskOS e ID+ foram restaurados. Um erro em uma implantação causou um pico temporário nas taxas de erro de nossos serviços entre 18:12 e 18:56 horário oriental. O erro foi corrigido e os serviços estão estáveis agora. Entendemos que esta interrupção é inaceitável e que uma ACR completa estará disponível assim que a análise completa da questão estiver concluída.
Os serviços Socure RiskOS e ID+ foram restaurados. Um erro em uma implantação causou um pico temporário nas taxas de erro de nossos serviços entre 18:12 e 18:56 horário oriental. O erro foi corrigido e os serviços estão estáveis agora. Entendemos que esta interrupção é inaceitável e que uma ACR completa estará disponível assim que a análise completa da questão estiver concluída.
# # ** Análise de Causas Root # **Incidente: ** Falta de APIs de socure **Data:** 15-Oct-2026 **Impacto:** Interrupção em serviço para APIs do Socure ** Status: ** Resolvido ### **1. Resumo** Em 15-out-2026, entre 18:12 e 19:00 horário oriental Socure experimentou uma interrupção em seus RiskOS e ID\+ APIs, causando erros e timeouts para os usuários. A primeira fase correu de 18:12 a 18:20, e foi uma grande interrupção para praticamente todos os serviços. A segunda fase da parada correu de 18:20 a 19:00, e foi uma parada parcial para serviços que dependem de dados KYC, onde os clientes viram elevadas taxas de erro e latências para alguns serviços, mas o tráfego ainda estava sendo servido. Tradução: ** Data / Hora \(ET\)** . **18:12** Uma mudança de limpeza de rotina é mesclada, movendo um repo fonte de um repositório de código para outro. Um bug em nossa ferramenta de revisão esconde o escopo da mudança. **18:13** ArgoCD reinicia a maioria dos serviços em um grande cluster Kubernetes ao mesmo tempo. **18:20** Todos os pods de serviço estão em execução. Serviço parcial de API restaurado, embora os serviços KYC ainda estejam vendo uma taxa de erro elevada. **18:21** A inundação de tráfego de inicialização sobrecarrega nosso serviço de pesquisa KYC. As taxas de erro aumentam. **18:42** O SRE diagnostica a falha da cascata que afeta o KYC Search e bloqueia o tráfego para que possa vir acima. **18:56** O serviço de pesquisa KYC está totalmente acima, e SRE retorna tráfego para ele. Os serviços a jusante estabilizam. **19:00** .. Todo o tráfego em funcionamento como normal, incidente declarado estável. # # # **3. Causa raiz # * ** Causa Primária:** Como parte de uma migração contínua, um SRE de plantão fez uma mudança para ArgoCD, o sistema que usamos para gerenciar os clusters Kubernetes A Socure executa seus serviços. A mudança foi dimensionada para um único cluster, foi revisada cuidadosamente antes de empurrar, não causou problemas em outros ambientes em que foi testado, e não deveria ter tido impacto visível. Infelizmente, a mudança atualizou uma configuração do legado que não apareceu na revisão da mudança. Essa configuração legada governava quais serviços a ArgoCD gerenciava e removeu muitos serviços ao vivo da ArgoCD. Em consequência, a ArgoCD retirou brevemente esses serviços da produção, antes de a configuração ser corrigida. * ** Fatores Contribuintes: ** O serviço de pesquisa KYC é uma peça de infraestrutura da Socure que fornece serviços para vários dos nossos produtos internos. Quando esse serviço foi reiniciado do zero ao mesmo tempo que todos os clientes do serviço, um pequeno número de pods no serviço caiu sob carga. Isso aumentou a carga nas cápsulas restantes, algumas das quais caíram por sua vez. Este fracasso em cascata impediu o serviço de voltar por conta própria, como fez o resto da infraestrutura da Socure. O diagnóstico desse modo de falha separado levou mais tempo, e remediando os erros restantes após o incidente inicial. # # # **4. Resolução # A mudança do ArgoCD foi revertida imediatamente, fazendo com que os serviços retornassem ao seu estado anterior. O serviço de pesquisa KYC exigiu esforço manual para bloquear o tráfego de alcançá-lo até que a maioria dos pods no serviço pudesse surgir. Depois que o serviço era saudável, nós poderíamos restaurar o tráfego para ele e resolver o incidente geral. ### **5. Ações corretivas e preventivas# 6. Lições aprendidas * A ferramenta da Socure para visualizar as mudanças que ela faz na produção não funcionou corretamente. Estamos revisando essas ferramentas para garantir que elas funcionem corretamente em todos os casos de uso e corrigir casos como este onde o escopo completo de uma mudança não é claro. * Aumente o processo de revisão de mudanças existente com suporte a agentes. Embora neste caso, a mudança específica não tenha sido visível no plano, ter um revisor suplementar que seja apoiado por um modelo de treinamento extenso ajudará a garantir que as questões sejam captadas antes da submissão. * Mesmo as mudanças que parecem não ter impacto, quando elas são feitas para o sistema de governança para os nossos empregos de produção, pode ser arriscado, e deve ser deslocado mais fora do horário comercial dos EUA. * O nosso serviço de pesquisa KYC é vulnerável a um problema de "troca-herdeiro" quando recebe fluxo de tráfego total quando não está totalmente online. Precisamos fortalecer nossos disjuntores para evitar que esta questão se repita. * Executamos muitos dos nossos principais serviços API em um único cluster kubernetes. Mesmo que esse cluster seja distribuído em várias zonas de disponibilidade, o plano de controle compartilhado cria um raio de explosão muito alto para mudanças nesse cluster. Próximos passos e compromisso contínuo A Socure entende que nossos clientes dependem de nós como um provedor chave em fluxos de negócios críticos, e que essa interrupção de serviço não é aceitável. Pedimos desculpa pelo impacto que esta questão causou e comprometemo-nos a garantir que ela não se repita. Para esse fim, forneceremos detalhes sobre nossos planos de re-arquitetar nosso layout de aplicação até novembro, bem como melhoraremos a resiliência do serviço de pesquisa KYC no Q1 do próximo ano.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos experimentando uma falha não planejada afetando o módulo eCBSV devido às respostas do SSA, resultando em erros de 5xx. A Socure contactou o fornecedor para investigar o problema e determinar quando o serviço deverá ser restaurado.
As taxas de erro diminuíram nos últimos minutos. Estamos monitorando essas taxas e aguardando a resposta do fornecedor.
A SSA experimentou um evento de impacto de serviços que afetou várias aplicações e serviços, incluindo o serviço de Verificação de Número de Segurança Social Baseada em Consentimento Eletrônico (eCBSV). A interrupção começou aproximadamente às 10:19 AM (ET) em 15 de outubro de 2026, e foi resolvida em aproximadamente 10:41 AM (ET). O serviço foi restaurado, e o eCBSV está operando normalmente neste momento.
Traduzido automaticamente da atualização oficial do incidente.
Nós experimentamos elevadas falhas de transação afetando Watchlist Plus e Watchlist Premier. A questão foi resolvida, e estamos monitorando o desempenho para garantir que os serviços permaneçam estáveis. Pedimos desculpa por qualquer inconveniente que isto possa ter causado.
Traduzido automaticamente da atualização oficial do incidente.
Estamos investigando um problema que causa atrasos no caso de atualizações serem refletidas na interface de gerenciamento de casos do RiskOS. Nossa equipe de engenharia está trabalhando ativamente para identificar a causa raiz e restaurar o comportamento normal de atualização. Forneceremos atualizações adicionais à medida que mais informações estiverem disponíveis. Isso não está impactando os pedidos de avaliação da API.
Identificamos a causa básica do problema que afeta atualizações na interface de gerenciamento de casos do RiskOS. Este problema é limitado a um subconjunto de casos e afeta especificamente a funcionalidade de Pesquisa de Casos, que pode mostrar temporariamente estados de caso desatualizados. Por favor, note que os dados do estado do caso exibidos dentro da Lista de Casos e páginas de Detalhes de Caso individuais são precisos e refletem o estado mais recente. Nossa equipe de engenharia implantou uma correção para todos os casos recém-atualizados e está trabalhando ativamente para re-sincronizar os casos afetados restantes para garantir a consistência dos dados através da pesquisa. Nós forneceremos outra atualização uma vez que o comportamento normal é totalmente restaurado.
O problema que afeta as atualizações do estado do caso foi resolvido. Todos os novos casos estão sendo processados corretamente. Pedimos sinceras desculpas por qualquer inconveniente que isso possa ter causado e apreciar sua paciência enquanto nossa equipe trabalhou para resolvê-lo.
Traduzido automaticamente da atualização oficial do incidente.
Entre 6:28 AM e 6:57 AM ET em 21 de setembro, um problema durante uma atividade operacional causou algumas notificações webhook associadas a avaliações mais antigas do mês passado para ser entregue novamente. As avaliações atuais e o processamento do webhook não foram impactados. A questão foi resolvida. Pedimos desculpas por qualquer confusão ou ruído adicional que isso possa ter causado.
Traduzido automaticamente da atualização oficial do incidente.
Estamos a investigar atrasos que afectam o processamento de lotes no painel. Os clientes podem experimentar o processamento atrasado enquanto revisamos o problema.
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Estamos observando maior latência afetando alguns clientes usando nossos produtos de fraude e sintéticos. A nossa equipa está a investigar a questão. As solicitações da API estão completando com sucesso, e não estamos observando nenhuma falha da API neste momento. Forneceremos atualizações adicionais à medida que mais informações estiverem disponíveis.
Estamos vendo uma melhoria na latência afetando alguns clientes usando nossos produtos de fraude e sintéticos. Continuaremos a acompanhar de perto a situação.
A questão que afecta os serviços de fraude e de síntese foi resolvida e o serviço voltou ao normal. Os clientes não devem continuar a sentir latência ou atrasos no acesso aos serviços de fraude e síntese
Traduzido automaticamente da atualização oficial do incidente.
Entre 8:30 e 2:00 PM EST, observamos um aumento nas taxas de erro de 5xx, o que resultou em erros intermitentes ou solicitações falhadas para alguns clientes. O impacto global foi mínimo, inferior a 0,01%. A taxa de erro voltou ao normal. Esta questão está totalmente resolvida neste momento. Pedimos desculpa por qualquer interrupção e apreciamos a sua paciência.
Traduzido automaticamente da atualização oficial do incidente.
Entre as 7:00 e 7:20 AM EST, observou-se um aumento nas taxas de erro de 5xx, o que pode ter resultado em erros intermitentes ou solicitações falhadas para alguns clientes. A taxa de erro voltou ao normal desde então, e estamos a investigar a causa raiz para garantir que resolvemos completamente o problema. Pedimos desculpa por qualquer interrupção e apreciamos a sua paciência.
** Análise de Causas Root **Incidente: ** Erros intermitentes elevados de 5xx entre serviços **Data:** 9 de setembro de 2026, 7:00 – 9:20 AM EDT \(aproximadamente 2 horas 20 minutos de impacto intermitente\) **Impacto:** Algumas solicitações submetidas à API do EmailAuthScore, e serviços relacionados, responderam de forma intermitente a erros. O impacto foi intermitente em vez de contínuo e foi limitado a janelas definidas descritas na linha do tempo abaixo. ** Status: ** Resolvido ### **1. Resumo** Em 9 de setembro de 2026, um aumento planejado na capacidade de processamento de backends levou a uma carga de conexão elevada em um componente de infraestrutura interna usado para apoiar o processamento a jusante para vários serviços. Este componente atingiu um limiar de capacidade interna, que introduziu atrasos no processamento e resultou em respostas intermitentes de erro na API do EmailAuthScore e serviços relacionados para um subconjunto de solicitações. A questão foi identificada através de uma combinação de monitoramento interno e relatórios durante a janela de impacto. A engenharia da Socure correlacionou os erros com a recente mudança de capacidade e reverteu-a, o que impediu o aumento inicial de erros. Um segundo aumento de erros, relacionado, ocorreu quando uma mudança de capacidade separada, feita mais cedo para um serviço interno diferente, colocou carga adicional no mesmo componente compartilhado; a engenharia aplicou mitigação adicional, após o que todos os serviços afetados retornaram à operação normal e estável. A secção 5 descreve as acções correctivas e preventivas a que a Socure se compromete, com prioridade na melhoria da visibilidade da capacidade da infra-estrutura e na prevenção de atrasos em qualquer componente interno que afecte o processamento de pedidos virados para o cliente. Tradução: Data / hora \(EDT\)** ** Eventos** --- --- --- --- Após um aumento planejado na capacidade de processamento de backend, a API do EmailAuthScore começou a retornar de forma intermitente as respostas de erro. □ 9 de Setembro de 2026 07:20 A mudança de capacidade recente foi revertida; as taxas de erro voltaram ao normal. 9 de setembro de 2026 08:45 AM** Uma mudança de capacidade separada feita antes para um serviço interno diferente colocou carga adicional no mesmo componente interno compartilhado, e a API do EmailAuthScore novamente começou a retornar respostas de erro intermitentes. □ 9 de Setembro de 2026 09:20 AM** Foram aplicadas reduções adicionais; as taxas de erro voltaram ao normal e permaneceram estáveis. 9 de Setembro de 2026 01:13 Como precaução, a Socure redirecionou temporariamente uma parte do processamento interno para longe do componente interno afetado para completar com segurança o aumento de capacidade restante. Não foram observados mais erros após esta alteração. # # # **3. Causa raiz # * ** Causa Primária:** Como parte do trabalho planejado para aumentar a capacidade do sistema antes da demanda prevista, a Socure aumentou a capacidade de processamento dos serviços de infraestrutura. Esta mudança aumentou o número de conexões para um componente de mensagens interna usado para suportar o processamento a jusante para esses serviços. Esse componente atingiu um limite de capacidade de conexão interna, que resultou em atrasos de conexão e processamento. Esses atrasos introduziram latência adicional e, em alguns casos, contrapressão no processamento de pedidos, o que contribuiu para taxas de erro intermitentes elevadas na API do EmailAuthScore e serviços relacionados para um subconjunto de solicitações durante as janelas de impacto descritas acima. * ** Fatores Contribuintes: ** * Um aumento súbito na demanda de capacidade de infraestrutura excedeu a capacidade que imediatamente não estava disponível no componente de mensagens internas. # # # **4. Resolução # Ao identificar que as elevadas taxas de erro estavam ligadas à recente mudança de capacidade, a Socure Engineering reverteu a mudança, o que impediu o aumento inicial de erros. Um segundo aumento relacionado de erros ocorreu quando uma mudança de capacidade separada, feita anteriormente para um serviço interno diferente, colocou carga adicional no mesmo componente compartilhado. A engenharia aplicou mitigação adicional, incluindo redirecionamento temporário de uma parte do processamento interno do componente afetado para os serviços impactados. Na sequência destas acções, todos os serviços afectados voltaram à operação normal e estável, que a Socure confirmou através de um acompanhamento contínuo. □ ### **5. Ações corretivas e preventivas# Descrição** ** ** ETA / Status** --- --- --- --- --- --- □ Otimizar a utilização da capacidade de infraestrutura □ Capacidade de serviço de infraestrutura ajustada e uso de conexão para garantir que o processamento permaneça dentro dos limites de infraestrutura suportados e para reduzir o risco de problemas relacionados com a capacidade similares. Feito • Aumentar a capacidade da infraestrutura de mensagens; Feito □ Melhorar o monitoramento e alerta de capacidade □ Adicionar monitoramento e alertas proativos para identificar possíveis restrições de capacidade de infraestrutura antes de afetar o desempenho do serviço. □ Em progresso. ETA 30 Set 2026. 6. Lições aprendidas * O monitoramento pró-ativo da infraestrutura de saúde precisa ser feito antes das mudanças de capacidade, não apenas o monitoramento de nível de aplicação. Próximos passos e compromisso contínuo Estamos empenhados em: * Completar as ações corretivas e preventivas listadas na Seção 5. * Melhorar a visibilidade para a saúde e a capacidade de infra-estrutura interna crítica antes da futura atividade de escala. * Fornecendo uma atualização de acompanhamento uma vez que todas as ações corretivas estão concluídas.
Traduzido automaticamente da atualização oficial do incidente.
Atualmente estamos investigando uma questão que criou um impacto nos serviços de monitoramento DocV e Watchlist onde erros foram observados hoje 8 de setembro, das 09:05 AM EST às 09:30 AM EST. Sistema recuperado, estamos trabalhando em determinar uma causa raiz neste momento.
O problema que impacta os serviços de monitoramento DocV e Watchlist em 8 de setembro foi resolvido. Nenhum impacto do cliente foi observado desde 10:35 AM EST. Pedimos desculpa por qualquer perturbação que isto possa ter causado.
# # # Análise de Causas Root # **Incidente:** Interrupção do Serviço Afetando o acesso de dados da conta **Data:** 8 de setembro de 2026 \(10:04 a 10:31 AM EDT\) **Impacto:** Monitores DocV e Watchlist ** Status: ** Resolvido ## # 1. Resumo Um esgotamento inesperado da capacidade do banco de dados da infraestrutura impediu temporariamente nossa plataforma de recuperar informações da conta para um subconjunto de solicitações do cliente. Durante a janela incidente \(10:04 a 10:31 AM EDT de 8-Sep-2026\), algumas das solicitações do cliente experimentaram taxas de erro elevadas ao tentar consultar detalhes da conta. Após uma atualização de manutenção de rotina, conexões simultâneas de ambientes de backup excederam os limiares normais, saturando a capacidade do banco de dados disponível. As equipes de engenharia desconectaram com segurança os ambientes redundantes e atualizaram as conexões ativas, restaurando a capacidade de resposta e estabilidade do sistema. ## #2. Timeline Data / hora \(ET\)** ** Eventos** --- --- --- --- O primeiro erro é: 10:04 AM EST, 8 Set 2026 □ Incidente reportado Grupo de conexão de ambiente redundante isolado □ Incidente resolvido □ 10:31 AM EST, 8 Set 2026 # # # 3. Causa raiz * ** Causa Primária:** Durante uma atualização programada do sistema, a retenção de conexão elevada entre ambientes de implantação levou à saturação do pool de conexão do banco de dados. Sob o pico de tráfego, isso causou atrasos de processamento e pedidos de tempo para serviços de plataforma dependentes. * ** Fatores Contribuintes: ** * Parâmetros rígidos de timeout de conexão atrasaram a liberação oportuna de alocações de banco de dados ociosos por ambiente passivo. * O nó de banco de dados inadequado headroom impediu o processamento contínuo de conexões extras geradas pelo ambiente de espera. * ** Fatores não contribuintes: ** * Nenhum # # # 4. Resolução A integridade total do serviço foi restaurada através das seguintes ações imediatas: 1. Isolando conexões de ambiente não-ativo para capacidade de agrupamento de banco de dados imediatamente livre. 2. Executando um reset rolling de nós de serviço ativos para restabelecer linhas de base de dados claras. □ 5. Ações corretivas e preventivas Descrição** ** ** ETA / Status** --- --- --- --- --- --- □ Melhorias nos padrões de acesso aos dados □ Melhorar a estratégia de cache e os padrões de acesso aos dados nos serviços internos que dependem dos dados das contas. 15 de Outubro de 2026 Gerência de Conexões Automatizadas Melhorar o gerenciamento do ciclo de vida da conexão e rotinas de limpeza automatizadas para tarefas de fundo inativas. 15 de Outubro de 2026 6. Lições aprendidas * ** Melhorar o isolamento da implantação: ** Estamos atualizando nossos procedimentos de implantação para garantir completa separação de recursos em ambientes ativos e passivos, eliminando a contenção de recursos entre ambientes durante as atualizações. * **Otimizando alocação de recursos de banco de dados:** Para garantir o desempenho máximo, estamos reequilibrando nossa carga de trabalho e aumentando a capacidade e eficiência global do sistema. 7. Próximos passos e compromisso contínuo Estamos empenhados em: * Resolver as causas raiz identificadas pelas linhas de tempo compartilhadas * Implementar guardas de segurança proativas e limiares de monitoramento, enquanto aplicações permanentes e melhorias de infraestrutura são finalizadas.
Traduzido automaticamente da atualização oficial do incidente.
Nosso Fornecedor, SSA, relatou que há atualmente um problema de latência elevado que afeta o módulo eCBSV. Como resultado, você pode experimentar tempos de resposta elevados. Nossa equipe está trabalhando ativamente com eles para resolver o problema o mais rápido possível. Pedimos desculpas por qualquer inconveniente que isso possa causar e apreciar sua paciência e compreensão.
A SSA resolveu a latência elevada que afetava o módulo eCBSV a partir das 2:00 AM ET. Os tempos de resposta voltaram ao normal. Obrigado pela vossa paciência e compreensão.
Traduzido automaticamente da atualização oficial do incidente.
We are investigating a slight degradation on the Watchlist product due to latency. Affecting both ID+ and RiskOS. The team is actively investigating this issue at this time.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Between 1:21 AM and 2:15 AM EDT on August 4, 2026, a subset of DocV webhook delivery notifications experienced elevated 401 response rates. The issue is fully resolved and webhook delivery is now operating normally. A full Root Cause Analysis (RCA) will be shared once the investigation concludes.
