Identificamos a causa do registro de domínio sendo incapaz de dar conselhos e estamos trabalhando na implementação de uma correção. Continuaremos a postar em nossa página de status com novas informações ou atualizações.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Console Problemas de Login
Início 13 Here 2026 da 15:03 UTC · 1h 13m
OutageCritical incident
Componentes afetados
ConsoleLearner Experience (LX)Console
investigating
Atualmente estamos investigando um problema que afeta o login do console. Nós forneceremos mais atualizações aqui quando disponível.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Em 13 de outubro de 2026, de aproximadamente 14:19 a 15:05 \(UTC\), os clientes em todas as regiões não foram capazes de fazer login no KnowBe4 Security Awareness Training \(SAT\) console, no KnowBe4 Learner Experience, e no PhishER console através do KnowBe4 SAT. Os logins SAML e senhas retornaram erros, e o console KnowBe4 SAT não apareceu na plataforma KnowBe4. Alguns processos de fundo, incluindo sincronização do usuário e e-mails de treinamento, também falharam durante este tempo.
O incidente foi causado por uma liberação de produção que entrou em conflito com outra mudança no nosso código. Nós revertemos o lançamento, e logins recuperados em todas as regiões entre 14:59 e 15:05 \(UTC\).
Nenhuma perda de dados ocorreu como resultado desta questão.
# # ** Causa da raiz #
Uma implantação de código removeu um valor de configuração inicial para acelerar o tempo de inicialização da aplicação. Um componente separado, adicionado ao nosso código após a alteração original ter sido testada, não foi responsável por esse valor alterado. Como resultado, cada tentativa de salvar um registro de usuário levantou um erro, incluindo a atualização que registra tentativas de login.
## ** Impacto do cliente
Os clientes em todas as regiões não puderam fazer login no console KSAT via SAML ou senha. Eles também não conseguiram acessar a Experiência do Aprendiz e não conseguiram acessar o console PhishER através do console KnowBe4 SAT. A criação de novos e-mails de usuário, sincronização de usuários e treinamento falhou durante este tempo, mas foram automaticamente re-experimentados após a implantação ser revertida.
## **Mitigação e reparação#
Descobrimos que a implantação removeu um valor de configuração que outro componente ainda necessitava. Isso foi atenuado revertendo a liberação, e confirmamos a recuperação em todas as regiões através de controles diretos e testes automatizados. Também revertemos a alteração original em nosso código fonte e preparamos uma versão corrigida que inclui uma correção de compatibilidade, para que a melhoria original possa ser reintroduzida com segurança.
** Medidas de prevenção
Estamos a adicionar verificações de código adicionais e testes para implantação.
Traduzido automaticamente da atualização oficial do incidente.
Prevenir e Proteger - Emissões de Envio de Suplemento Web (apenas UE)
Início 13 Here 2026 da 08:47 UTC · 4h 55m
OutageMajor incident
Componentes afetados
Web Add-InWeb Add-In
investigating
Recebemos relatórios de que o KnowBe4 Email Security Add-in está mostrando o erro "O add-in KnowBe4 email security está impedindo que esta mensagem seja enviada" ao enviar e-mails. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
monitoring
Implementamos uma correção para os erros de envio do Web Add-in e estamos monitorando os resultados para garantir que não ocorram mais problemas.
resolved
Este incidente foi resolvido.
postmortem
De segunda-feira, 12 de outubro de 2026, aproximadamente 14:25 \(UTC\), a terça-feira, 13 de outubro de 2026, em torno de 15:07 \(UTC\), alguns clientes em casos da UE de Prevent and Protect tiveram dificuldade de enviar e-mails do Microsoft Outlook. Mensagens afetadas não foram enviadas, e o add-in KnowBe4 Email Security mostrou o seguinte erro: "O add-in KnowBe4 Email Security está impedindo que esta mensagem seja enviada."
Esta edição foi causada por um erro na forma como uma versão add-in foi preparada para lançamento, que produziu duas cópias ligeiramente diferentes da mesma versão. Quando o Outlook carrega o add-in, ele baixa um conjunto de arquivos que devem corresponder. Em casos da UE, o Outlook às vezes recebeu arquivos de ambas as cópias, então o add-in não pôde terminar de carregar, e a mensagem não foi enviada. Alguns dispositivos também salvaram o download falhou, então o erro continuou nesses dispositivos até que uma correção foi aplicada. Para resolver este problema, nossa equipe corrigiu os arquivos adicionais da UE para que cada cliente receba um conjunto correspondente. Em seguida, lançamos uma versão atualizada do add-in para todas as regiões, que limpou quaisquer erros salvos. O suplemento KnowBe4 Email Security retornou ao desempenho normal por volta de 15:07 \(UTC\) em 13 de outubro de 2026.
Para evitar esse tipo de problema no futuro, estamos mudando como versões adicionais são preparadas e lançadas, para que cada versão produza sempre o mesmo conjunto de arquivos e cada cliente receba a mesma versão ao mesmo tempo. Também estamos alterando o add-in para que os downloads falhados de arquivos add-in não sejam salvos em dispositivos. Por fim, estamos adicionando alertas para erros de carregamento adicionais para detectá-los mais cedo.
Nenhuma perda de dados ocorreu como resultado desta questão.
Traduzido automaticamente da atualização oficial do incidente.
Prevenir e proteger o desempenho degradado (Instalações dos EUA)
Início 28 Gwengolo 2026 da 21:10 UTC · 3d 13h
IssuesMinor incident
Componentes afetados
Mail FlowMail Flow
investigating
Atualmente estamos investigando um problema relativo ao desempenho degradado para Prevenir e Proteger em nossos servidores dos EUA.
monitoring
Identificamos um problema com as instâncias de Prevenir e Proteger dos EUA que resultou em desempenho degradado. Foi implementada uma solução e continuaremos a acompanhar esta questão.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
De segunda-feira, 28 de setembro de 2026, em aproximadamente 16:00 \(UTC\), a quarta-feira, 30 de setembro de 2026, em torno de 12:35 \(UTC\), alguns clientes experimentaram atraso de fluxo de correio e problemas intermitentes acessar instâncias dos EUA de Prevent and Protect.
Em 28 de setembro, nosso monitoramento mostrou intenso tráfego de rede, com picos no topo de cada hora. Alguns clientes começaram a ter problemas intermitentes acessando instâncias dos EUA dos consoles Prevent and Protect. Procuras internas que o processamento de e- mail depende do timing inicial, e as mensagens foram colocadas em fila como resultado. Os clientes relataram o problema à nossa equipe de suporte, e nós postamos um aviso de página de status. Desempenho recuperado mais tarde naquele dia como o tráfego dos EUA diminuiu.
Em 29 de setembro, nossos engenheiros revisaram os dados do dia anterior nos gateways de correio, nos serviços internos de que dependem e na camada de rede. Atrasos de fluxo de correio e problemas de acesso ao console retornaram brevemente, em seguida, facilitou como o tráfego de rede diminuiu, seguindo o mesmo padrão de 28 de setembro.
Em 30 de setembro, de aproximadamente 12:19 para 12:35 \ (UTC\), nossa equipe aumentou a capacidade dos serviços de rede dos EUA enquanto o serviço continuou. Sua carga caiu imediatamente após a mudança, e Prevent and Protect retornou ao desempenho normal por volta de 12:35 \(UTC\) em 30 de setembro de 2026. Monitoramos o pico de tráfego em 30 de setembro e 1 de outubro e não vimos recidivas.
Nenhuma perda de dados ocorreu como resultado desta questão.
# # ** Causa da raiz #
Esta questão foi causada por um limite de capacidade nos serviços de rede que lidam com o tráfego para os nossos serviços de processamento de correio dos EUA. Durante o pico de tráfego, e especialmente durante os picos horários, os serviços de rede não puderam processar conexões rapidamente o suficiente. Este atraso adicional ao tráfego que passa por eles e fez com que algumas conexões caíssem.
Esse tráfego incluía pedidos internos que nossos gateways de e-mail enviam para procurar membros da lista de distribuição, então as políticas certas são aplicadas. Estes pedidos estão sujeitos a um limite de tempo estrito para que uma procura lenta não possa conter o processamento de correio indefinidamente. Quando os serviços de rede atrasaram os pedidos para além desse limite, falharam. Como resultado, o processamento do e-mail diminuiu e as mensagens foram em fila de espera.
Dois fatores dificultaram a identificação da questão. Em primeiro lugar, alguns pedidos internos também utilizaram estes serviços de rede e foram afectados pelo limite de capacidade. Em segundo lugar, os serviços de rede começaram a se degradar antes de seu uso de computação atingir níveis que normalmente sinalizariam um problema. Monitoramento de computação padrão não captou a saturação da rede, então a causa levou mais tempo para identificar. Encontrar uma maneira segura de aumentar a capacidade sem interromper o serviço também levou tempo, por isso a correção foi aplicada em 30 de setembro.
## **Mitigação e reparação#
Descobrimos que os serviços de rede dos EUA não tinham capacidade suficiente para lidar com o tráfego de pico. Mitigamos isso aumentando sua capacidade de uma forma que manteve o serviço funcionando durante toda a mudança. Após o aumento de capacidade, os serviços de rede lidaram com o pico de tráfego sem mais problemas.
Também descobrimos que o uso de computação sozinho não era um sinal confiável de saturação de rede. Expandimos nosso monitoramento para rastrear indicadores de saúde da rede além do uso de computação.
Finalmente, descobrimos que era difícil encontrar onde falhasse pedidos internos. Adicionamos o registro que mostra onde os pedidos internos falham e o tempo passa.
## ** Impacto do cliente
Durante o pico de tráfego norte-americano em 28 e 29 de setembro, alguns clientes sofreram atrasos no processamento e entrega de correio de entrada e saída através de Prevent and Protect. As mensagens endereçadas às listas de distribuição podem ter sido processadas mais lentamente, enquanto as buscas foram repetidas. Alguns clientes também tiveram dificuldade intermitente de acessar ou usar o console dos EUA.
O impacto facilitou a cada dia, à medida que o tráfego dos EUA diminuiu, e o correio em fila foi processado uma vez recuperada a capacidade. Após a mudança em 30 de setembro, não vimos mais degradação durante o pico de tráfego.
** Medidas de prevenção
Para evitar esse tipo de problema no futuro, aumentamos a capacidade dos serviços de rede dos EUA e ampliamos nosso monitoramento para rastrear indicadores de saúde da rede, além do uso de computação. Também adicionamos login para melhorar a visibilidade em solicitações internas falhadas.
Traduzido automaticamente da atualização oficial do incidente.
Proteger e prevenir o desempenho degradado - EUA
Início 24 Gwengolo 2026 da 17:53 UTC · 15h 23m
IssuesMinor incident
Componentes afetados
Mail FlowConsoleMail Flow
investigating
Identificamos um problema com a Protect que resultou em desempenho degradado, e nossa equipe de engenharia está procurando uma solução.
monitoring
Identificámos um problema com a Protect que resultou em desempenho degradado. Foi implementada uma solução e continuaremos a acompanhar esta questão.
investigating
Nós identificamos um problema com Protect & Prevent que resultou em desempenho degradado, e nossa equipe de engenharia está olhando para uma correção.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
De quinta-feira, 24 de setembro de 2026, aproximadamente 17:07 \(UTC\), a sexta-feira, 25 de setembro de 2026, em torno de 09:16 \(UTC\), alguns clientes experimentaram lentidão intermitente, erros, e atraso de fluxo de correio para as instâncias dos EUA de Proteger e Prevenir.
Em 24 de setembro, um pico anormalmente grande no tráfego de e-mail colocou carga sustentada nos serviços de rede que lidam com o tráfego para o nosso processamento de correio dos EUA. Nosso monitoramento nos alertou em aproximadamente 17:07 \(UTC\). Alguns clientes viram acesso lento ou intermitente a Proteger e erros ocasionais ao carregar páginas ou opções avançadas. O acesso foi inconsistente, então alguns clientes poderiam usar Protect enquanto outros viram erros. O processamento de mensagens através de instâncias dos EUA diminuiu, e algumas mensagens foram adiadas ou não apareceram na caixa de entrada de moderação quando esperado.
O desempenho parecia melhorar, então mudamos o nosso aviso de status para Monitoramento às 18:39 \(UTC\). O problema mais tarde se repetiu, e os clientes relataram lentidão contínua para nossa equipe de suporte. Às 19:57 \(UTC\), mudamos o aviso de volta para Investigar e expandi-lo para também incluir Prevent como o impacto ficou mais claro.
Nossa equipe monitorou os sistemas afetados enquanto o volume de correio elevado diminuiu. À medida que a carga nos serviços de rede voltou ao normal, o processamento de e-mail recuperado e as filas de e-mail retornaram ao normal durante a noite. Confirmamos que Protect estava carregando normalmente e que as mensagens de teste estavam sendo entregues novamente, e então continuou o monitoramento. Proteger e Prevenir retornou ao desempenho normal por volta de 09:16 \(UTC\) em 25 de setembro de 2026.
Nenhuma perda de dados ocorreu como resultado desta questão.
# # ** Causa da raiz #
Este problema foi causado por um pico anormalmente grande no tráfego de e-mail. O volume aumentado colocou uma carga sustentada nos serviços de rede que lidam com o tráfego para o nosso processamento de correio dos EUA.
Esses serviços de rede operam dentro de limites de capacidade fixos, e sua capacidade não poderia ser aumentada durante o pico. Porque eles não conseguiam acompanhar a onda, eles desaceleraram, e algum processamento falhou intermitentemente. Como resultado, um grande volume de e-mail foi colocado em fila de espera no processamento de e-mails dos EUA, algumas páginas e ações em Proteger erros devolvidos, e algumas mensagens foram adiadas ou não apareceram na caixa de entrada de moderação quando esperado.
Dois fatores dificultaram a gestão da questão. Primeiro, porque o acesso falhou intermitentemente, algumas verificações tiveram sucesso enquanto os clientes continuaram a ver erros, tornando a recuperação mais difícil de confirmar. Em segundo lugar, nosso monitoramento mostrou carga máxima nos serviços de rede mais claramente do que a carga atual, o que tornou mais difícil avaliar em tempo real se a carga ainda estava elevada.
## **Mitigação e reparação#
Descobrimos que os serviços de rede que lidam com o processamento de correio dos EUA alcançaram seus limites de capacidade fixa durante o pico de tráfego, e sua capacidade não pôde ser aumentada durante o evento. Nossa equipe monitorou os sistemas afetados, enquanto o volume de correio elevado diminuiu e a carga de serviço de rede voltou ao normal. O processamento do correio foi então recuperado, e o correio em fila foi processado.
Como a questão já havia aparecido melhorar antes da repetição, confirmamos a recuperação de várias formas antes de resolver o incidente. Confirmamos que Protect estava carregando normalmente, que as mensagens de teste estavam sendo entregues através do processamento de correio dos EUA, e que as solicitações de suporte estavam progredindo normalmente. Também monitoramos durante a noite e não recebemos novos relatórios de clientes em instâncias dos EUA.
## ** Impacto do cliente
Alguns clientes tiveram acesso lento ou intermitente para Proteger, e ocasionalmente viram erros ao carregar páginas ou opções avançadas. O processamento do correio através de instâncias dos EUA foi atrasado para Proteger e Prevenir. Em alguns casos, as mensagens foram adiadas ou não apareceram na caixa de entrada de moderação quando esperado.
Os clientes cujo e-mail é criptografado, descriptografado ou moderado à medida que passa através do nosso processamento de e-mail dos EUA eram mais propensos a ser afetados. A maioria Proteger os clientes usando o add-in não foram afetados pelos atrasos de processamento de correio. Os consoles Protect e Prevent permaneceram disponíveis, embora algumas ações do console tenham sido afetadas pelo processamento de e-mail mais lento.
** Medidas de prevenção
Para evitar esse tipo de problema no futuro, estamos melhorando nosso monitoramento de aumentos incomuns no volume de email. Também estamos melhorando nosso monitoramento para mostrar a carga atual em nossos serviços de rede, não apenas valores de pico. Além disso, estamos avaliando maneiras de dimensionar nossa capacidade de rede de forma mais dinâmica durante picos de tráfego súbitos e avaliando melhorias de longo prazo na infraestrutura de rede que lida com o processamento de correio dos EUA.
Desde então, também aumentamos a capacidade dos serviços de rede dos EUA em resposta a[ um incidente posterior](https://status.knowbe4.com/incidents/9wc6rjm8g70v).
Traduzido automaticamente da atualização oficial do incidente.
Proteger, Prevenir, Espaço de Trabalho e Webforms
Início 23 Gwengolo 2026 da 09:52 UTC · 5h 6m
IssuesMinor incident
Componentes afetados
Secure WorkspaceAuthenticationAuthenticationSecure Web Forms
identified
Recebemos relatórios de usuários recebendo mensagens de erro "Acesso negado" ao tentar fazer login. Identificamos o problema e estamos trabalhando na implementação de uma solução e atualizaremos esta página quando tivermos mais informações.
monitoring
O problema foi identificado e uma correção foi implementada e irá atualizar esta página quando tivermos mais informações.
resolved
Este incidente foi resolvido com sucesso e todos os sistemas estão totalmente operacionais.
Traduzido automaticamente da atualização oficial do incidente.
Webforms □ Questão de submissão parcial (apenas Reino Unido)
Início 23 Gwengolo 2026 da 09:00 UTC · 5h 58m
IssuesMinor incident
Componentes afetados
Secure Web Forms
investigating
Recebemos relatórios de que alguns usuários não são capazes de enviar submissões com sucesso. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
identified
A questão foi identificada e uma correção foi implementada. Uma atualização com mais informações seguirá em conformidade.
monitoring
O problema foi identificado e uma correção foi implementada e irá atualizar esta página quando tivermos mais informações.
resolved
Este incidente foi resolvido com sucesso e todos os sistemas estão totalmente operacionais.
postmortem
Na quarta-feira, 23 de setembro de 2026, de aproximadamente 08:15 a 11:18 \(UTC\), alguns clientes experimentaram lentidão e falhas de submissão de formulários em instâncias do Reino Unido de Secure Webforms.
Esta questão foi causada por limites de desempenho da base de dados no ambiente de produção do Reino Unido após uma mudança recente. Uma configuração de banco de dados também fez algumas consultas serem executadas de forma ineficiente. Como resultado, os tempos de resposta aumentaram e algumas submissões de formulários falharam. Para resolver esse problema, nossa equipe pausou temporariamente uma tarefa de sincronização de fundo para reduzir a carga, ajustou as configurações do banco de dados para melhorar a eficiência da consulta e aumentou o rendimento de armazenamento. Os formulários Web seguros retornaram ao desempenho normal em 11:18 \(UTC\).
Para evitar este tipo de problema no futuro, estamos adicionando monitoramento adicional para a largura de banda do banco de dados. Também estamos melhorando a eficiência da tarefa de sincronização de fundo.
Nenhuma perda de dados ocorreu como resultado desta questão.
Traduzido automaticamente da atualização oficial do incidente.
Proteger o Acesso Web - Erro ao Enviar E-mails (apenas Reino Unido)
Início 21 Gwengolo 2026 da 09:32 UTC · 22h 55m
IssuesMinor incident
Componentes afetados
Web Access
investigating
Recebemos relatórios de que os usuários são incapazes de enviar e-mails via Web Access (Secure Message Portal) na região do Reino Unido, com Erro "503 Serviço Indisponível". Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
monitoring
Nós implementamos uma correção e estamos monitorando os resultados.
monitoring
Continuamos monitorando quaisquer outros problemas.
resolved
Este incidente foi resolvido com sucesso e todos os sistemas estão totalmente operacionais.
postmortem
Na segunda-feira, 21 de setembro de 2026, de aproximadamente 08:55 até terça-feira, 22 de setembro de 2026, aproximadamente 14:30 \(UTC\), alguns usuários experimentaram erros e não foram capazes de enviar e-mails via Acesso web \(Secure Message Portal\) na região do Reino Unido.
Esse incidente foi causado por um erro de configuração durante uma atualização do banco de dados, o que levou à interrupção intermitente do serviço. Para resolver esse problema, revertemos a configuração e o Web Access retornou ao desempenho normal às 14:30 \(UTC\) em 22 de setembro de 2026.
Para evitar esse tipo de problema no futuro, estamos revisando e atualizando nossa configuração de banco de dados.
Nenhuma perda de dados ocorreu como resultado desta questão.
Traduzido automaticamente da atualização oficial do incidente.
KSAT - Não foi possível iniciar sessão (DE e UK Only)
Início 18 Gwengolo 2026 da 11:07 UTC · 5h 40m
OutageCritical incident
Componentes afetados
Console
investigating
Recebemos relatórios de que os usuários são incapazes de fazer login nas instâncias DE e UK do KSAT. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Em 17 de setembro de 2026, uma tarefa de fundo arquivou um grande grupo de usuários e correu como uma única transação de banco de dados sem limites. Esta transação bloqueou um grande número de linhas de usuário, fazendo com que os logins da região dos EUA se limitem porque eles escrevem para a mesma tabela. Após atingir um limite de execução da plataforma, o trabalho foi encerrado e automaticamente tentado cinco vezes em intervalos de 15 minutos, resultando em uma interrupção de 75 minutos. Para resolver o problema, implantamos uma correção que desacoplou logins da fechadura. Em seguida, implantamos uma correção de seguimento para uma regressão introduzida pela mudança de login, bem como para o trabalho de arquivo.
* O que aconteceu *
Uma mudança anterior moveu a ação "arquivo de todos os usuários" de uma solicitação web síncrona, time-out para uma tarefa de fundo ilimitada. Quando um grande grupo de usuários foi arquivado, isso desencadeou a nova tarefa de fundo. O trabalho bloqueou todas as linhas de usuário afetadas em uma única transação, realizando por usuário escreve e uma chamada de serviço externo síncrono antes de comprometer. Tentativas de login, que escrevem para a mesma tabela, foram na fila atrás do trabalho bloqueado e cronometrado para os usuários dos EUA.
Quando o trabalho chegou a um limite de execução de 15 minutos na plataforma, foi encerrado no meio da transação, a transação voltou, e o trabalho foi transferido para a fila. Esse ciclo ocorreu cinco vezes, resultando em uma interrupção de 75 minutos. Quando falhas foram detectadas internamente em 22:35 \(UTC\), um incidente foi declarado, e um engenheiro foi chamado para responder. A mitigação para dissociar a ação de escrita do fluxo de login foi implantada em aproximadamente 23:44 \(UTC\).
A mitigação em si causou uma regressão: qualquer usuário em qualquer região que tivesse previamente erroneamente digitado uma senha não poderia mais entrar porque resets para tentativas de login falhou tentou escrever para um banco de dados somente leitura. Por volta de 09:17 \(UTC\) em 18 de setembro de 2026, a correção para esta regressão foi implantado em todas as regiões. A questão original do trabalho do arquivo só dos EUA voltou duas vezes mais entre 13:45 e 14:05 \(UTC\) antes de uma correção permanente foi implantado em aproximadamente 15:00 \(UTC\).
O incidente foi totalmente resolvido até 19:12 \(UTC\) em 18 de setembro de 2026.
# # ** Causa da raiz #
Um trabalho de fundo de uma única transação para arquivo de usuário de grande grupo tinha bloqueios exclusivos em muitas linhas afetadas, bloqueando a escrita da própria linha do processo de login. Uma alteração anterior para mover esta operação para fora de um tempo- limite de solicitação web e para uma tarefa de fundo removido o único limite restante de sua duração. O limite de execução de 15 minutos da plataforma desencadeou ciclos automáticos de morte e entrega, repetindo a contenção de bloqueio cinco vezes e resultando em uma janela de saída de 75 minutos.
## **Encontros e Mitigações#
Descobrimos que a transação de arquivo ilimitado bloqueou um grande número de linhas de usuário afetadas, bloqueando outras tabelas. Isso foi atenuado a curto prazo por dissociar a dependência de escrita do processo de login da tabela afetada, e então corrigido a longo prazo, corrigindo o trabalho de arquivo. Também descobrimos que a concordância desordenada do trabalhador amplifica a contenção de bloqueio. Isso foi atenuado em curto prazo, reduzindo manualmente a concorrência dos trabalhadores. A solução a longo prazo para cambalear e serializar estes trabalhos está planeada. Finalmente, descobrimos que a regressão de login-fix causou falhas de login de todas as regiões para usuários com tentativas falhadas anteriores, porque as escritas foram rejeitadas por um banco de dados somente para leitura. Isso foi corrigido através de uma mudança de código direcionada que foi implantada e verificada em todas as regiões.
** ** Medidas preventivas
Estamos melhorando nossas operações de arquivo de grandes grupos, limitando-as, processando-as em lotes pequenos e comprometidos e mantendo chamadas externas fora da transação do banco de dados. Estamos também adicionando uma mudança-check para um trabalhador de fundo específico para pular escreve que não mudar nada. Finalmente, estamos adicionando alertas diretos para a idade da transação do banco de dados e atrasos de purga, além de verificações indiretas periódicas.
## ** Impacto e Recuperação do Cliente
Falhas de login duraram aproximadamente 75 minutos na região dos EUA. Duas breves recidivas ocorreram na manhã seguinte e foram limpas manualmente em minutos. Algumas ações administrativas, como o gerenciamento de usuários, também foram afetadas. Os logins dos parceiros não foram afetados. A regressão secundária durou cerca de 10 horas e afetou todas as regiões para usuários que antes haviam falhado em uma tentativa de login. Na tarde de 18 de setembro, a recuperação total foi confirmada em todas as regiões, e a página de status foi marcada como resolvida.
Nenhuma perda de dados ocorreu como resultado desta questão.
## **Conclusão
Uma única transação de fundo sem limites, combinada com um mecanismo de repetição automático, causou uma falha de login na região dos EUA. O trabalho de gatilho específico e seu comportamento de repetição foram corrigidos, e o login não depende mais do caminho de escrita competido. Uma regressão do mesmo incidente e duas pequenas recidivas foram resolvidas em poucas horas. O restante trabalho preventivo, incluindo a coordenação dos trabalhadores e o acompanhamento das transacções de bases de dados, é monitorizado acima.
Traduzido automaticamente da atualização oficial do incidente.
KSAT - Não foi possível iniciar sessão (apenas nos EUA)
Início 17 Gwengolo 2026 da 22:44 UTC · 18h 3m
OutageCritical incident
Componentes afetados
Console
investigating
Recebemos relatórios de que os usuários são incapazes de fazer login na instância americana do KSAT. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
monitoring
Implementamos uma correção e estamos monitorando os resultados para garantir que não ocorram mais problemas.
investigating
Recebemos novos relatórios de usuários que não conseguiram acessar a instância americana do KSAT. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Em 17 de setembro de 2026, uma tarefa de fundo arquivou um grande grupo de usuários e correu como uma única transação de banco de dados sem limites. Esta transação bloqueou um grande número de linhas de usuário, fazendo com que os logins da região dos EUA se limitem porque eles escrevem para a mesma tabela. Após atingir um limite de execução da plataforma, o trabalho foi encerrado e automaticamente tentado cinco vezes em intervalos de 15 minutos, resultando em uma interrupção de 75 minutos. Para resolver o problema, implantamos uma correção que desacoplou logins da fechadura. Em seguida, implantamos uma correção de seguimento para uma regressão introduzida pela mudança de login, bem como para o trabalho de arquivo.
* O que aconteceu *
Uma mudança anterior moveu a ação "arquivo de todos os usuários" de uma solicitação web síncrona, time-out para uma tarefa de fundo ilimitada. Quando um grande grupo de usuários foi arquivado, isso desencadeou a nova tarefa de fundo. O trabalho bloqueou todas as linhas de usuário afetadas em uma única transação, realizando por usuário escreve e uma chamada de serviço externo síncrono antes de comprometer. Tentativas de login, que escrevem para a mesma tabela, foram na fila atrás do trabalho bloqueado e cronometrado para os usuários dos EUA.
Quando o trabalho chegou a um limite de execução de 15 minutos na plataforma, foi encerrado no meio da transação, a transação voltou, e o trabalho foi transferido para a fila. Esse ciclo ocorreu cinco vezes, resultando em uma interrupção de 75 minutos. Quando falhas foram detectadas internamente em 22:35 \(UTC\), um incidente foi declarado, e um engenheiro foi chamado para responder. A mitigação para dissociar a ação de escrita do fluxo de login foi implantada em aproximadamente 23:44 \(UTC\).
A mitigação em si causou uma regressão: qualquer usuário em qualquer região que tivesse previamente erroneamente digitado uma senha não poderia mais entrar porque resets para tentativas de login falhou tentou escrever para um banco de dados somente leitura. Por volta de 09:17 \(UTC\) em 18 de setembro de 2026, a correção para esta regressão foi implantado em todas as regiões. A questão original do trabalho do arquivo só dos EUA voltou duas vezes mais entre 13:45 e 14:05 \(UTC\) antes de uma correção permanente foi implantado em aproximadamente 15:00 \(UTC\).
O incidente foi totalmente resolvido até 19:12 \(UTC\) em 18 de setembro de 2026.
# # ** Causa da raiz #
Um trabalho de fundo de uma única transação para arquivo de usuário de grande grupo tinha bloqueios exclusivos em muitas linhas afetadas, bloqueando a escrita da própria linha do processo de login. Uma alteração anterior para mover esta operação para fora de um tempo- limite de solicitação web e para uma tarefa de fundo removido o único limite restante de sua duração. O limite de execução de 15 minutos da plataforma desencadeou ciclos automáticos de morte e entrega, repetindo a contenção de bloqueio cinco vezes e resultando em uma janela de saída de 75 minutos.
## **Encontros e Mitigações#
Descobrimos que a transação de arquivo ilimitado bloqueou um grande número de linhas de usuário afetadas, bloqueando outras tabelas. Isso foi atenuado a curto prazo por dissociar a dependência de escrita do processo de login da tabela afetada, e então corrigido a longo prazo, corrigindo o trabalho de arquivo. Também descobrimos que a concordância desordenada do trabalhador amplifica a contenção de bloqueio. Isso foi atenuado em curto prazo, reduzindo manualmente a concorrência dos trabalhadores. A solução a longo prazo para cambalear e serializar estes trabalhos está planeada. Finalmente, descobrimos que a regressão de login-fix causou falhas de login de todas as regiões para usuários com tentativas falhadas anteriores, porque as escritas foram rejeitadas por um banco de dados somente para leitura. Isso foi corrigido através de uma mudança de código direcionada que foi implantada e verificada em todas as regiões.
** ** Medidas preventivas
Estamos melhorando nossas operações de arquivo de grandes grupos, limitando-as, processando-as em lotes pequenos e comprometidos e mantendo chamadas externas fora da transação do banco de dados. Estamos também adicionando uma mudança-check para um trabalhador de fundo específico para pular escreve que não mudar nada. Finalmente, estamos adicionando alertas diretos para a idade da transação do banco de dados e atrasos de purga, além de verificações indiretas periódicas.
## ** Impacto e Recuperação do Cliente
Falhas de login duraram aproximadamente 75 minutos na região dos EUA. Duas breves recidivas ocorreram na manhã seguinte e foram limpas manualmente em minutos. Algumas ações administrativas, como o gerenciamento de usuários, também foram afetadas. Os logins dos parceiros não foram afetados. A regressão secundária durou cerca de 10 horas e afetou todas as regiões para usuários que antes haviam falhado em uma tentativa de login. Na tarde de 18 de setembro, a recuperação total foi confirmada em todas as regiões, e a página de status foi marcada como resolvida.
Nenhuma perda de dados ocorreu como resultado desta questão.
## **Conclusão
Uma única transação de fundo sem limites, combinada com um mecanismo de repetição automático, causou uma falha de login na região dos EUA. O trabalho de gatilho específico e seu comportamento de repetição foram corrigidos, e o login não depende mais do caminho de escrita competido. Uma regressão do mesmo incidente e duas pequenas recidivas foram resolvidas em poucas horas. O restante trabalho preventivo, incluindo a coordenação dos trabalhadores e o acompanhamento das transacções de bases de dados, é monitorizado acima.
Traduzido automaticamente da atualização oficial do incidente.
Emissão de Login/Acesso ao Console - (Instituição do Reino Unido)
Início 16 Gwengolo 2026 da 17:47 UTC · 3h 11m
OutageCritical incident
Componentes afetados
ConsoleLearner Experience (LX)Console
identified
Identificamos um problema que causa problemas de login e acesso para contas em nossa instância do Reino Unido.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Defender e-mails não sendo renderizados no clássico Outlook
Início 8 Gwengolo 2026 da 07:00 UTC · 0m
Pending
resolved
Em Septermber 8o, fizemos conhecimento de que e-mails HTML incorporados renderizados parcialmente ou em branco no Outlook clássico devido a uma atualização de biblioteca HTML de rotina no motor de remoção de código prejudicial da Defender interagindo com o motor de renderização de Word legado do Outlook clássico. Novo Outlook e Outlook na web não foram afetados. Este foi estritamente um problema de exibição: nenhum e-mail foi atrasado, perdido ou comprometido, e a detecção de ameaça permaneceu totalmente ativa. A engenharia reverteu a atualização para restaurar a renderização normal. Se você desativou temporariamente a remoção de código prejudicial durante esta janela, por favor, reative-a para garantir a proteção completa.
Traduzido automaticamente da atualização oficial do incidente.
Área de trabalho □ E-mail questões de verificação MFA
Início 4 Gwengolo 2026 da 10:53 UTC · 2d 21h
IssuesMinor incident
Componentes afetados
Secure Workspace
investigating
Recebemos relatórios de um problema com a entrega de verificação de E-mail MFA para o espaço de trabalho.
Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
monitoring
Recebemos relatórios de que o problema com a entrega de verificação de E-mail MFA for Workspace foi atenuado pela Microsoft, e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
PhishER - Atrasos no Processamento de Mensagens
Início 26 Eost 2026 da 16:19 UTC · 3h 32m
IssuesMinor incident
Componentes afetados
Inbox
investigating
Nós identificamos um problema onde os usuários podem experimentar atrasos nas mensagens sendo processadas, e nossa equipe de engenharia está olhando para uma correção.
monitoring
Nossa equipe de engenharia implementou uma correção para o problema que causa atraso no processamento de mensagens na PhishER, e estamos monitorando os resultados.
resolved
Nossa equipe de engenharia implementou uma correção para o problema que causa atraso no processamento de mensagens na PhishER.
postmortem
## **Resumo #
Durante uma implantação de rotina em 26 de agosto de 2026, uma estrutura de gerenciamento de infraestrutura inesperadamente removeu as filas de processamento de mensagens primárias e as filas secundárias que contém mensagens que não puderam ser processadas. Isso resultou em uma interrupção temporária da entrega de email para as caixas de entrada dos clientes PhishER.
Nenhuma perda de dados ocorreu como resultado desta questão.
# # ** Causa da raiz #
Em 24 de agosto de 2026, uma mudança de configuração interna deixou registros de configuração ao vivo fora de sincronia com nosso código. Uma atualização posterior do código não reverte esses registros.
Quando uma implantação de produção de rotina foi realizada em 26 de agosto de 2026, o código de configuração ativo não continha os registros de recursos realocados. Como resultado, a implantação tratou as filas ativas como recursos não gerenciados e as removeu.
## **Mitigação e reparação#
O monitoramento automatizado nos alertou para uma queda no processamento de mensagens, e uma equipe de resposta de incidentes foi reunida.
Descobrimos que as filas tinham sido apagadas. Isso foi atenuado a curto prazo, refazendo os trabalhos de produção afetados para recriar as filas em falta.
Em seguida, verificamos que o processamento de e-mail em tempo real tinha retomado. Finalmente, repetimos as cargas de e-mail mantidas no armazenamento em nuvem durante a falha nas caixas de entrada dos clientes.
** Timeline
Todos os tempos estão em UTC.
* 24 de agosto de 2026, 18:41:** Uma mudança interna de configuração escreveu registros de recursos atualizados na configuração de produção ao vivo.
* 26 de agosto de 2026, 15:15: Uma implantação de produção removeu as filas de entrada e as filas que contêm mensagens que não puderam ser processadas em produção, interrompendo a entrega de email nas caixas de entrada dos clientes.
* 26 de agosto de 2026, 15:59: Nosso monitoramento automatizado alertou a equipe de engenharia para zero mensagens sendo processadas, e uma equipe de resposta de incidentes foi bipada.
* 26 de agosto de 2026, 16:01: Confirmamos que as filas haviam sido apagadas e verificamos que as cargas de e-mail recebidas ainda eram armazenadas com segurança.
* 26 de agosto de 2026, 16:15:** Identificamos o descompasso de configuração como a causa principal da raiz.
* 26 de agosto de 2026, 16:25: Nossa equipe reescreveu os empregos de produção afetados, e as filas foram recriadas.
* 26 de agosto de 2026, 18:44:** Nosso replay automatizado terminou de entregar todos os e-mails atrasados para as caixas de entrada dos clientes.
** Medidas de prevenção
Para evitar esse tipo de problema no futuro, removemos uma etapa de configuração ao vivo das verificações pré-fusão e separamos o planejamento de implantação das mudanças de produção. Também adicionamos verificações automatizadas para confirmar a saúde da fila após os lançamentos estarem completos.
## ** Impacto do cliente
De 15:15 a 16:25 \(UTC\) em 26 de agosto de 2026, e-mails enviados à PhishER não foram processados em caixas de entrada do cliente.
As cargas de e-mail de entrada foram armazenadas com segurança no armazenamento em nuvem durante toda a interrupção. Depois que as filas foram restauradas, um replay automatizado entregue e-mails mantidos nas caixas de entrada dos clientes. Todas as mensagens de atraso foram entregues por 18:44 \(UTC\).
Nenhum e-mail do cliente foi perdido como resultado deste problema.
Traduzido automaticamente da atualização oficial do incidente.
PAB □ Relatório de erro Phish usando o botão de alerta Gmail Phish
Início 21 Eost 2026 da 08:52 UTC · 6h 5m
IssuesMinor incident
Componentes afetados
Phish Alert Button
investigating
Recebemos relatórios de que o botão Alerta Gmail Phish mostra o erro "[reportPhishAtttempt()] Ocorreu um erro interno. Por favor, tente novamente." ao relatar phish. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
identified
A questão foi identificada e está a ser implementada uma solução.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
Na sexta-feira, 21 de agosto de 2026, de aproximadamente 05:20 a 12:55 \(UTC\), alguns clientes experimentaram falhas intermitentes ao usar o Gmail Phish Alert Button add-in para relatar e-mails suspeitos, recebendo a mensagem "Um erro interno ocorreu" em vez de uma confirmação de relatório de sucesso. A questão afectou os clientes em todas as regiões, com os maiores volumes de erros concentrados nas regiões de serviços UE-Oeste e EUA-Leste.
Este problema foi causado por uma interrupção em um serviço de cache na plataforma do Google Apps Script, na qual o add-in depende para armazenar a configuração de sessão por usuário. O serviço começou a retornar intermitentemente resultados vazios na leitura enquanto ainda aceitava novas escritas, fazendo com que as submissões de relatórios afetados falhassem. KnowBe4 engajou o Google diretamente e arquivou um relatório de bug formal entre aproximadamente 12:19 e 12:39 \(UTC\). O volume de erro diminuiu acentuadamente pouco tempo depois, à medida que a condição do lado do fornecedor foi limpa, e o botão de alerta Gmail Phish retornou ao desempenho normal em aproximadamente 12:55 \(UTC\).
Para evitar esse tipo de problema no futuro, continuamos a trabalhar com o Google para rastrear a resolução do defeito de cache subjacente. Nenhuma perda de dados ocorreu como resultado desta questão.
Traduzido automaticamente da atualização oficial do incidente.
PAB enviando um relatório de não entrega após um e-mail é reportado (apenas EUA)
Início 18 Eost 2026 da 14:29 UTC · 5h 45m
IssuesMinor incident
Componentes afetados
Phish Alert Button
investigating
Estamos investigando um problema que faz com que um Relatório de Não Entrega (NDR) seja devolvido quando uma mensagem é reportada através do botão Alerta Phish e "Enviar-nos uma Cópia" está habilitado nas configurações da conta
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
Na terça-feira, 18 de agosto de 2026, de aproximadamente 14:10 a 14:55 \(UTC\), os clientes usando o botão de alerta Phish \(PAB\) com o **Enviar-nos uma cópia** recurso habilitado recebeu relatórios de não entrega para o **Enviar-nos uma cópia** caixa postal.
Este problema foi causado por uma mudança de configuração para a infraestrutura de roteamento de email compartilhado. Essa mudança renomeou um componente de mensagens usado tanto pelos nossos ambientes de estadiamento como de produção. Como uma regra de produção dependia desse componente compartilhado, o renome causou falhas de entrega para o **Enviar-nos uma cópia** caixa postal e desencadeou relatórios de não entrega. Para resolver esse problema, nossa equipe atualizou a configuração afetada para referenciar o componente correto, e o recurso **Enviar cópia** retornou ao desempenho normal até 14:55 \(UTC\).
Para evitar esse tipo de problema no futuro, estamos separando configurações de roteamento de email para nossos ambientes de encenação e produção. Estamos também a conciliar configurações legadas com os nossos actuais padrões de gestão de infra-estruturas.
Nenhuma perda de dados ocorreu como resultado desta questão.
Traduzido automaticamente da atualização oficial do incidente.
Google Workspace PhishRIP errors
Início 5 Eost 2026 da 19:29 UTC · 1d 2h
IssuesMinor incident
Componentes afetados
PhishRIP
investigating
We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.
monitoring
Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.
resolved
Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.
Configurações da conta SAT não Carregando
Início 4 Eost 2026 da 19:19 UTC · 16h 58m
IssuesMinor incident
Componentes afetados
Console
identified
Identificamos um problema que impede as configurações da conta de carregar no console SAT.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
Na terça-feira, 4 de agosto de 2026, de aproximadamente 18:22 a 19:43 \(UTC\), alguns clientes experimentaram problemas carregando a página **Conte Configurações** no console KnowBe4 em todas as regiões da CA, DE, UE, Reino Unido e EUA.
Este problema foi causado por uma série de alterações de aplicação que aumentou a complexidade de uma solicitação GraphQL usada pela experiência Configurações de Conta. Cada alteração permaneceu abaixo do limiar de complexidade configurado da plataforma quando avaliada individualmente, mas combinada, a solicitação ultrapassou esse limiar e impediu o carregamento da página. A engenharia identificou o limiar de complexidade como fator contribuinte e implantou uma mudança corretiva a partir de aproximadamente 19:14 \(UTC\). Após a correção ser verificada nas regiões afetadas, o console KnowBe4 retornou ao desempenho normal em aproximadamente 19:43 \(UTC\).
Para evitar esta questão no futuro, aumentamos o limiar de complexidade.
Nenhuma perda de dados ocorreu como resultado desta questão.
Traduzido automaticamente da atualização oficial do incidente.
Emails inesperados em quarentena pela PhishRIP
Início 28 Gouere 2026 da 20:00 UTC · 22h 58m
IssuesMinor incident
Componentes afetados
PhishRIP
investigating
Estamos investigando um problema relacionado com e-mails sendo colocados em quarentena pela PhishRIP inesperadamente
monitoring
Uma correção foi implementada para este problema e as consultas do PhishRIP não estão mais quaranteando mensagens inesperadamente. Ainda estamos investigando consultas que podem ter sido impactadas
resolved
Este incidente foi resolvido.
postmortem
## **Resumo #
Em 28 de julho de 2026, uma atualização para o serviço PhishRIP fez com que algumas consultas de pesquisa PhishRIP combinassem mais amplamente do que deveriam. E-mails benignos que não atenderam aos critérios de remetente configurados foram colocados em quarentena em algumas contas de clientes.
Monitoramento automatizado e tickets de suporte ao cliente surgiram rapidamente. A engenharia reverteu a mudança dentro de aproximadamente 25 minutos após declarar o incidente e parou a quarentena não intencional. A engenharia então restaurou manualmente os e-mails de quarentena incorreta para as caixas de entrada dos clientes.
# # ** Causa da raiz #
Em 28 de julho de 2026, implantamos uma atualização de manutenção para o serviço de consulta por trás da PhishRIP. Esta atualização foi projetada para melhorar o manuseio de endereços de remetentes inválidos, permitindo que o sistema volte a pesquisar apenas a parte de domínio do endereço.
No entanto, a lógica de validação existente usou uma expressão regular que exigia um símbolo "@" no campo remetente. Quando uma consulta usou um domínio nu, como [example.com](http://example.com) sem nome de usuário ou símbolo "@", o regex marcou o domínio como inválido.
Este conflito entre a validação existente e a atualização de pesquisa de domínio fez com que o sistema largasse inteiramente os critérios do remetente. A consulta correu contra caixas de entrada usando apenas seus parâmetros restantes, correspondência e quarentena de e-mails bem fora do remetente pretendido.
** Timeline
Todos os tempos estão em UTC.
Tempo** ** Eventos**
--- --- --- ---
Nosso monitoramento automatizado detectou padrões anômalos de execução de consultas e alertou nossos engenheiros, que imediatamente começaram a investigar. □
O problema foi aumentado para um incidente de produção de alta gravidade, e uma equipe de resposta foi montada. □
Nossa equipe de suporte aumentou os primeiros tickets de clientes que relataram quarentenas inesperadas, corroborando o alerta de monitoramento.
A causa raiz foi rastreada para uma implantação recente da API de consultas, e a engenharia começou a reverter a mudança.
As comunicações de incidentes foram postadas em nossa página de status, com o PhishRIP marcado como Degradado.
20:16 A implantação foi totalmente revertida.
As verificações de produção confirmaram que as consultas de assunto e domínio estavam de novo a corresponder apenas aos seus alvos pretendidos, e que não havia mais mensagens em quarentena por erro. Nossa página de status foi atualizada em conformidade. □
A engenharia começou a restaurar os e-mails de quarentena incorreta.
As restaurações foram concluídas para todos os conjuntos de consultas de clientes registrados através de nossa equipe de suporte.
## **Mitigação e reparação
** Reversão do código.** Nós pesamos parando operações PhishRIP ativo no meio da corrida contra reverter o código. Parar as tarefas de fundo teria interrompido fluxos de trabalho de segurança legítimos para cada inquilino, então reverter foi a melhor opção. O reverso do código foi implantado e verificado na produção dentro de aproximadamente 40 minutos após a escalada.
** Restauração de email. Para evitar o lançamento de emails genuinamente maliciosos de volta aos ambientes do cliente, nós os restauramos manualmente ao invés de em massa. A Engenharia usou ferramentas internas de administração para restaurar e-mails em lotes, e trabalhou com o Suporte para verificar cada identificação de conta, identificação de consulta e receber a aprovação do cliente primeiro. Todas as contas relatadas foram restauradas durante a noite.
** ** Medidas preventivas
* ** Cobertura de regressão**: Estamos adicionando testes de unidade e integração para consultas somente de domínio, não padrão e remetente de texto nu para capturar esses casos de entrada antes da implantação.
* **Query guardrails**: Estamos adicionando uma verificação no motor de consulta que bloqueia consultas de execução se seus parâmetros de filtragem de núcleo são deixados cair durante a avaliação.
## **Conclusão
Uma única regra de validação causou isso: um regex que assumiu que cada campo de remetente continha um `@`. Quando as consultas usaram um domínio nu, essa suposição deixou cair o filtro do remetente e as consultas combinaram muito mais e- mail do que o pretendido. A correção foi simples uma vez que encontramos, e o reverso parou o dano em cerca de 25 minutos após declarar o incidente.
Restaurar o correio em quarentena foi um processo mais difícil: não conseguimos restaurar e-mails em massa sem arriscar e-mails genuinamente maliciosos voltando para caixas de entrada. Nossa equipe optou por proceder com cuidado, trabalhando conta por conta com Suporte durante toda a noite.
Duas medidas preventivas teriam captado isso antes: um teste cobrindo somente consultas de remetentes de domínio, e um guardrail que se recusa a executar uma consulta quando seu filtro de remetentes foi despojado. Ambos estão agora planeados. O problema imediato está resolvido, e todas as contas relatadas foram restauradas.
Glossário
* ** PhishRIP:** Uma funcionalidade PhishER que permite aos administradores pesquisar e colocar em quarentena e-mails de phishing correspondentes em cada caixa de entrada do usuário em uma organização.
* **Regex \(expressão regular\):** Um padrão usado no software para pesquisar texto e validar entrada, como verificar se um endereço de e-mail é formatado corretamente.
* ** Reversão de código:** Retirando uma atualização de software para retornar à versão estável anterior.
Traduzido automaticamente da atualização oficial do incidente.
Proteja página de compra em branco no store.knowbe4.com
Início 17 Gouere 2026 da 13:18 UTC · 56d 1h
OutageMajor incident
Componentes afetados
KnowBe4 Website
investigating
Estamos investigando usuários sendo incapazes de comprar Proteja licenças no store.knowbe4.com. Atualizaremos esta página quando tivermos mais informações.
monitoring
Implementamos uma correção e estamos monitorando os resultados para garantir que não ocorram mais problemas.
investigating
Recebemos relatórios de que os clientes são incapazes de comprar Protect licenças em store.knowbe4.com. Estamos investigando este problema e atualizaremos esta página quando tivermos mais informações.
monitoring
Implementamos uma correção para a loja online e estamos monitorando os resultados para garantir que não ocorram mais problemas.
monitoring
Continuamos a monitorar a correção implementada para a loja online, para garantir que não ocorram mais problemas.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
