Histórico de interrupções do Harness

1. 27 Here 2026 da 19:52 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 27 Here 2026 da 19:58 UTCinvestigating

   Os gasodutos CI na infraestrutura VM estão falhando na etapa Inicializar porque a tarefa vai para um delegado fora do pool pretendido

3. 27 Here 2026 da 21:15 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

4. 27 Here 2026 da 22:16 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

5. 27 Here 2026 da 22:24 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 19 Here 2026 da 07:46 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 19 Here 2026 da 08:02 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 19 Here 2026 da 08:04 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 19 Here 2026 da 08:21 UTCresolved

   Este incidente foi resolvido.

5. 23 Here 2026 da 18:21 UTCpostmortem

   ## **Resumo # Em 19 de outubro de 2026, entre aproximadamente 12:10 e 12:55 PDT, os clientes da Prod4 experimentaram erros e indisponibilidade intermitente dos serviços Harness Pipelines. As execuções de dutos pesados levaram a um aumento acentuado no uso da CPU e memória no serviço de dutos, e por um curto período todas as instâncias de serviço estavam indisponíveis. A engenharia Harness escalou o serviço tanto verticalmente como horizontalmente, que restaurou o serviço. Está a ser feita uma correcção para o comportamento subjacente. # # ** Causa da raiz # Em 19 de outubro, o elevado número de execuções simultâneas com gráficos de execução muito grandes levou a um aumento acentuado nos recursos de cluster. O serviço armazena e recupera este gráfico completo de execução para fins de visualização e avançando ainda mais para os próximos estados. Nossos auto-scalaers no Prod4 levaram mais tempo do que o normal para escalar recursos devido a um aumento acentuado na CPU e memória. Como parte da correção, a atualização do gráfico de execução agora processará mudanças incrementais no gráfico em vez do gráfico completo. Está a ser lançada de forma faseada e será completamente lançada no mais curto prazo. ## **Impacto# * Usuários afetados: Clientes no Prod4. * Sintoma: indisponibilidade de funcionalidade de pipeline na plataforma Harness. * Dados: Nenhuma perda de dados. * Solução sugerida: Nenhum exigido dos clientes. Engenharia Harness resolveu o problema. * Duração do impacto: Aproximadamente 20 minutos de indisponibilidade total e desempenho degradado por 25 minutos. O Harness continuou o monitoramento após a recuperação e confirmou a estabilidade da plataforma com os clientes. ## **Remediação# **Imediato** A engenharia de Harness escalou o serviço de pipeline tanto verticalmente \(mais recursos por instância\) quanto horizontalmente \(mais instâncias\), e removeu instâncias em um estado não saudável. A contagem de instância estabilizada e o serviço normal foram restaurados. O sistema manter-se-á em escala até que a correção seja completamente executada. ** Itens permanentes de correção e ação ** Para evitar que tais questões aconteçam novamente, Harness é 1. Ajustando o processo auto curar/escalar de modo que o impacto é mimimal a nenhum. 2. Otimizando o fluxo do grafo de execução para que grandes gráficos possam ser processados mais rápido.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Here 2026 da 10:10 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 15 Here 2026 da 10:10 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 15 Here 2026 da 10:27 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Here 2026 da 08:04 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 15 Here 2026 da 08:05 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 15 Here 2026 da 08:09 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 15 Here 2026 da 08:15 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Here 2026 da 01:06 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 13 Here 2026 da 01:07 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 13 Here 2026 da 01:56 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 13 Here 2026 da 04:29 UTCresolved

   Este incidente foi resolvido.

5. 23 Here 2026 da 03:16 UTCpostmortem

   . .

Traduzido automaticamente da atualização oficial do incidente.

1. 12 Here 2026 da 15:25 UTCinvestigating

   Atualmente estamos experimentando erros HTTP 429 (limite de taxa) quando a Harness Cloud constrói acesso à Maven Central, que pode afetar a execução da construção. Nossa equipe está trabalhando ativamente com Sonatype para resolver o problema o mais rápido possível. Apresentaremos mais actualizações à medida que avançarmos.

2. 12 Here 2026 da 19:31 UTCresolved

   Este incidente foi resolvido.

3. 23 Here 2026 da 03:06 UTCpostmortem

   tldr: \(Houve uma breve limitação de taxa por maven central\) Mais detalhes a seguir

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Here 2026 da 10:23 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

2. 8 Here 2026 da 10:53 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 21:46 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 6 Here 2026 da 21:47 UTCinvestigating

   Continuamos a investigar esta questão.

3. 6 Here 2026 da 22:03 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

4. 6 Here 2026 da 22:30 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

5. 6 Here 2026 da 22:30 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados. Temos a confirmação desta solução.

6. 6 Here 2026 da 22:44 UTCresolved

   Este incidente foi resolvido.

7. 23 Here 2026 da 02:12 UTCpostmortem

   # 1. Resumo Em 6 de outubro de 2026, dutos contendo um estágio de IaCM não foram capazes de iniciar em Prod1 por aproximadamente duas horas. Usuários afetados viram um erro quando o pipeline tentou criar seu plano de execução. Pipelines que não usaram uma fase IaCM continuaram a funcionar normalmente. A causa subjacente foi um defeito de registro interno no serviço que lida com a execução do estágio de IaCM: sob uma condição específica, rara, o próprio sistema de registro desse serviço poderia acabar esperando por si mesmo indefinidamente, o que, por sua vez, atrasou o processo mais amplo responsável pela preparação de planos de execução do gasoduto. O problema foi desencadeado por uma explosão incomum de atividade de log do pipeline de um cliente. Resolvemos o impacto imediato rodando o serviço de volta para sua versão estável anterior, e uma correção de código permanente está atualmente em teste. # 2. Impacto * Todos os oleodutos usando um palco IaCM no Prod1 não foram capazes de iniciar por aproximadamente duas horas. * Vários clientes no cluster Prod1 foram afetados. * Pipelines que não usaram um estágio IaCM não foram afetados e continuaram rodando normalmente. * Nenhum dado foi perdido como resultado deste incidente. * Como efeito colateral do rollback usado para resolver este incidente, uma correção não relacionada para um cliente \(extendendo quanto tempo um determinado token de autenticação permanece válido durante pipelines\) foi temporariamente revertida. Essa solução foi reaplicada na mesma noite. # 3. Causa raiz O serviço responsável pelas etapas de pipeline IaCM registra sua atividade através de uma fila interna: mensagens de log são colocadas na fila, e um único trabalhador de background lê continuamente e escreve as mensagens. Separadamente, esse serviço tem um filtro que pode reescrever a gravidade de certas mensagens de log de volta para essa mesma fila. Sob uma condição de tempo específico e estreita, isso criou um impasse, se a fila acontecesse de estar completamente cheia no exato momento em que uma mensagem reescrita estava sendo enviada de volta para ela, o único trabalhador responsável por liberar espaço na fila ficaria preso esperando o espaço para liberar, uma condição que nunca poderia resolver, já que era a única coisa que poderia ter liberado esse espaço. Uma vez que isso aconteceu, todas as outras partes do serviço que precisava registrar qualquer coisa também ficou preso esperando, que em cascata para o processo pipeline-plan-criação falhando para qualquer pipeline usando uma fase IaCM. # 4. Resolução * Rolou o serviço de volta para sua última versão estável, que resolveu o incidente imediato. 5. Ações Preventivas 1. **Otimizar o defeito subjacente**: Otimize e ajuste o filtro de registro para que a reescrita da gravidade de uma mensagem aconteça no thread que gerou a linha de registro, em vez de ser resubmetida através da mesma fila de trabalhador de fundo, eliminando a condição de impasse inteiramente. 2. ** Melhor monitoramento na saúde da fila de registro**: adicionar métricas e alertar nesta fila interna para que esta classe de páginas de saturação nossa equipe de plantão automaticamente em vez de confiar em relatórios de clientes. 3. **Avaliar limites e realizar testes de alta tensão com gasodutos muito grandes**:

Traduzido automaticamente da atualização oficial do incidente.

1. 16 Here 2026 da 10:41 UTCresolved

   Em 7 de outubro de 2026, das 08:00 UTC às 11:00 UTC (1:30 PM às 16:30 PM IST), algumas execuções de gasodutos no cluster Prod 7 viram falhas intermitentes nas avaliações de etapas da Política (OPA).

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 12:54 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

2. 6 Here 2026 da 15:35 UTCresolved

   Este incidente foi resolvido.

3. 10 Here 2026 da 01:57 UTCpostmortem

   Resumo Os clientes no Prod 2 experimentaram falhas intermitentes de alguns passos de verificação na inicialização. As etapas afetadas falharam pouco tempo após o lançamento com uma mensagem indicando que a Verificação Contínua\(CV\) não poderia alcançar um serviço interno do Harness. O problema decorreu de uma recente atualização de serviço que introduziu o agrupamento de conexões para melhorar o desempenho e confiabilidade com uma configuração keep-vive incompatível com o tempo de espera do serviço receptor. Nenhum dado do cliente foi perdido ou corrompido. # # Impacto do Cliente Os clientes que usam o CV Verify steps on Prod-2 viram falhas intermitentes durante a janela incidente. A taxa de falha foi baixa — a maioria das execuções concluídas com sucesso em toda a janela. Os pipelines que não utilizaram CV Verify não foram afetados. Causa raiz Uma atualização recente do serviço de CV introduziu o agrupamento de conexão a um componente interno da plataforma, com uma duração de manutenção viva maior do que o tempo livre desse componente. Conexões inativas por tempo suficiente foram silenciosamente fechadas pelo servidor; o serviço CV não detectou isso e não teve lógica de repetição para tais falhas, fazendo com que elas surgissem diretamente como Verificando falhas de passos. O problema foi intermitente porque só afetou conexões que por acaso estavam ociosas tempo suficiente para expirar. Mitigação A duração de permanência da conexão foi reduzida para se enquadrar no tempo livre do serviço receptor. Falhas caíram para quase zero imediatamente, e não foram observadas falhas adicionais deste tipo em qualquer ambiente de produção. Próximos Passos Para evitar a recorrência, Harness irá: * ** Manuseio de conexão fixa:** Ajustado o padrão manter-vivo e habilitado retentar automático em falhas de conexão de modo que os erros de conexão são tratados de forma transparente. * ** Adicione resiliência na inicialização do passo:** Introduza novamente com backoff para a chamada de serviço interno no início do passo de verificação, para que falhas transitórias isoladas não surjam como falhas de passo imediatas. * **Melhorar o alerta:** Monitoramento aprimorado das taxas de erro de conexão interna.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Here 2026 da 11:58 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 6 Here 2026 da 11:59 UTCinvestigating

   Continuamos a investigar esta questão.

3. 6 Here 2026 da 12:24 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

4. 6 Here 2026 da 16:21 UTCresolved

   Este incidente foi resolvido.

5. 9 Here 2026 da 18:48 UTCpostmortem

   # # Resumo Em **Terça-feira, 6 de outubro de 2026**, os pipelines IaCM que usam o plugin **OpenTofu** em **Prod1** falharam intermitentemente para uma conta de produçãoAfetados executam segredos injetados com sucesso, em seguida, os passos posteriores cronometraram ou falharam a autenticação. O mesmo oleoduto muitas vezes teve sucesso na repetição, sem mudança de configuração. As execuções falhantes típicas correram por cerca de 90 minutos. Outros módulos Harness não foram amplamente impactados. Não temos nenhum relatório de perda de dados do cliente. Os tubos que terminaram dentro da vida útil do símbolo não foram afetados por este defeito. # # Causa raiz Os estágios IaCM cunharam tokens de autenticação que expiraram após uma hora. A política verifica mais tarde a longo prazo, em seguida, rejeitou o token, então o passo cronometrado ou autenticação falhada. Aquela vida de uma hora foi fixa. Correções de cerca de 90 minutos cruzaram a marca de uma hora, razão pela qual as falhas apareceram em tubulações mais longas e muitas vezes limpas em uma repetição mais curta. Um conjunto separado de erros de plano na mesma conta veio da configuração credencial no espaço de trabalho do cliente e está fora deste incidente. # # Impacto * ** Área do produto:** Os pipelines IaCM usam os plugins IaCM falando com o OPA sdk. * ** Experiência do cliente:** Tempo limite intermitente e falhas de autenticação após injeção secreta, em corridas de mais de uma hora. * **Ambiente:**Prod1, uma conta de produção * ** Dados:** Nenhuma perda de dados relatada. □ # # Remediação * **Imediato:** Abriu uma página de status para a conta Prod1 afetada, e enviou uma mudança interina do gerenciador IaCM para uma classe das falhas observadas enquanto a correção do plugin foi construída. * ** Permanente:** Enviado um hotfix do plugin OpenTofu para que a expiração do token seja configurável. Na produção, a vida útil foi elevada para cerca de 6 horas, de modo que um longo gasoduto não sobrevive ao símbolo. O hotfix foi validado em QA e implantado no Prod1. Pedimos desculpa pela perturbação causada. Por favor, contacte o seu contacto de suporte Harness se tiver mais perguntas.

Traduzido automaticamente da atualização oficial do incidente.

1. 5 Here 2026 da 22:01 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 5 Here 2026 da 23:50 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 6 Here 2026 da 00:26 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 6 Here 2026 da 00:26 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

5. 6 Here 2026 da 00:39 UTCresolved

   Verifiquei os problemas SSO corrigidos e resolvidos.

6. 9 Here 2026 da 16:17 UTCpostmortem

   # # Okta Aplicação SP-Iniciou falhas de login SSO □ Resumo □ Entre 5 de outubro de 2026, 18:18 UTC e 6 de outubro de 2026, 00:26 UTC, alguns clientes de Harness não foram capazes de entrar no servidor MCP Harness hospedado via SAML Single Sign-On \(SSO\). A autenticação principal do usuário do Harness Portal permaneceu totalmente operacional. Usuários afetados viram erros de login ou foram redirecionados para uma página SSO inválida em vez de completar o login. □ O problema foi causado pela quebra de mudanças em uma atualização de versão do Harness identity service HarnessID. Nós corrigimos com uma série de hotfixes, e o login SSO foi totalmente restaurado para todos os clientes afetados. □ Impacto □ Os usuários que se inscreveram no Harness MCP via SAML SSO não conseguiram completar a autenticação. Sessões MCP existentes que dependiam de SSO não puderam ser atualizadas, então alguns usuários tiveram que entrar novamente e não puderam. Os logins não SSO para MCP hospedado funcionaram durante a maior parte do incidente. Nenhum dado do cliente foi perdido ou exposto. Os clientes que utilizaram sua própria configuração genérica de aplicação SAML 2.0 em Okta não foram afetados. Causa raiz Em 29 de setembro de 2026, uma versão atualizada do aplicativo Harness foi publicada para a Okta Integration Network. A atualização adicionou suporte para registrar várias URLs de resposta \(ACS\) para que os clientes executando Harness em várias regiões ou ambientes pudessem configurar mais de uma URL de retorno. □ Harness inclui um valor AssertionConsumerServiceURL na solicitação de autenticação SAML que envia para Okta. Antes desta atualização, Okta não validou esse valor para instâncias de aplicação sem URLs ACS adicionais configuradas e em vez disso retornou a asserção SAML para URL ACS padrão da aplicação. Após a atualização, esta validação tornou-se ativa em todas as instâncias de aplicação existentes, incluindo aquelas em que o cliente nunca tinha configurado uma URL ACS adicional. Como o valor solicitado não estava presente na lista registrada da instância, Okta devolveu um erro HTTP 400. □ A aplicação atualizada passou pela revisão padrão de publicação OIN da Okta, que inclui verificação de compatibilidade backward contra instalações existentes da integração publicada. Essa mudança no comportamento de validação para instâncias sem URLs adicionais de ACS configuradas não foi revelada durante essa revisão, então ela chegou aos clientes no momento do lançamento. Remediação **Resposta imediata □ Duas soluções foram publicadas na página de status: inscreva-se a partir da peça Harness em Okta \(IdP-iniciated login\), que não foi afetada, ou registre a URL Okta SSO da aplicação no campo URLs ACS adicionais da aplicação Harness Okta. O Harness envolveu cada cliente afetado relatado diretamente e validou seu login. □ **Resolução** □ Rodando o aplicativo de volta para a versão anterior foi deliberadamente evitado, pois isso só iria adiar a mesma perturbação para a próxima versão. Cada cliente afetado foi desbloqueado através do registro de URL ACS, e estamos trabalhando com Okta para tornar a validação de URL ACS condicional novamente, para que instâncias sem URLs ACS adicionais configuradas se comportem exatamente como antes, e nenhuma ação do cliente é necessária. Itens de Ação Para evitar que tais questões aconteçam novamente, Harness tomará os seguintes itens de ação □ 1. Trabalhando com Okta para restaurar a validação condicional de URL ACS, então instâncias sem URLs ACS adicionais configuradas se comportam exatamente como antes e nenhuma ação do cliente é necessária. 2. Publique um guia de configuração dedicado para o aplicativo Harness OIN na documentação Harness, incluindo os requisitos de resposta \(ACS\) URL. 3. Adicione uma etapa de verificação pré-lançamento independente contra configurações de clientes existentes para qualquer atualização futura para o aplicativo Okta publicado, juntamente com a própria revisão de Okta. 4. Migrar a autenticação do usuário para Harness ID, que remove a dependência deste comportamento de validação inteiramente.

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Gwengolo 2026 da 20:31 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 29 Gwengolo 2026 da 20:31 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 29 Gwengolo 2026 da 20:57 UTCidentified

   Identificamos um problema que se aplica apenas ao login iniciado pelo SP através do aplicativo Harness Okta publicado. Após uma atualização recente para essa aplicação, essas tentativas de login retornaram um erro HTTP 400 quando o URL SSO configurado estava faltando de URLs ACS adicionais. As configurações gerais do SAML 2.0 no Okta não são afetadas. Soluções imediatas: Usar o login iniciado pelo IDP. Iniciar o login da peça de aplicação Harness em Okta. Ou Adicione seu URL SSO Harness a URLs ACS adicionais no aplicativo Harness Okta publicado.

4. 2 Here 2026 da 00:33 UTCresolved

   Este incidente foi resolvido.

5. 7 Here 2026 da 18:30 UTCpostmortem

   # 1. Resumo A partir de 29 de setembro de 2026, os clientes que entraram no Harness através do aplicativo Harness publicado na Okta Integration Network \(OIN\) não conseguiram concluir o login SSO iniciado pelo SP. Usuários afetados receberam um erro HTTP 400 do Okta em vez de serem conectados. A questão foi introduzida por uma mudança na forma como Okta validou a resposta solicitada \(ACS\) URL para instalações existentes do aplicativo Harness publicado. As soluções foram publicadas dentro de uma hora após o primeiro relatório, e cada cliente afetado foi desbloqueado. # 2. Impacto □ * O impacto foi limitado aos clientes usando o aplicativo Harness publicado da Okta Integration Network for SP-iniciated login \(starting sign-in from Harness\). Essas tentativas retornaram um erro HTTP 400 do Okta. * O login iniciado por IdP, iniciado a partir da telha Harness em Okta, continuou a funcionar durante todo o processo. * Os clientes usando sua própria configuração genérica de aplicação SAML 2.0 em Okta não foram afetados. * Nenhum dado do cliente foi perdido ou exposto. # 3. Causa raiz Em 29 de setembro de 2026, uma versão atualizada do aplicativo Harness foi publicada para a Okta Integration Network. A atualização adicionou suporte para registrar várias URLs de resposta \(ACS\) para que os clientes executando Harness em várias regiões ou ambientes pudessem configurar mais de uma URL de retorno. Harness inclui um valor AssertionConsumerServiceURL na solicitação de autenticação SAML que envia para Okta. Antes desta atualização, Okta não validou esse valor para instâncias de aplicação que não tinham URLs ACS adicionais configuradas, e simplesmente retornou a asserção SAML para URL ACS padrão da aplicação. Após a atualização, esta validação tornou-se ativa em todas as instâncias existentes da aplicação, incluindo aquelas em que o cliente nunca tinha configurado uma URL ACS adicional. Como o valor solicitado não estava presente na lista registrada da instância, Okta rejeitou a solicitação de autenticação com um erro HTTP 400. O aplicativo atualizado passou pela revisão padrão de publicação OIN da Okta, que inclui verificação de compatibilidade backward contra instalações existentes de uma integração publicada. Essa mudança no comportamento de validação para instâncias sem URLs adicionais de ACS configuradas não foi revelada durante essa revisão, então chegou aos clientes no lançamento. 4. Remediação **Resposta imediata Duas soluções foram publicadas na página de status: iniciar sessão da peça Harness no Okta \(IdP-iniciated login\), que não foi afetado; ou registrar o aplicativo Okta SSO URL no campo URLs ACS adicionais da aplicação Harness Okta. O suporte envolveu cada cliente afetado diretamente e validou o login com eles. □ **Resolução** Rodando o aplicativo de volta para a versão anterior foi deliberadamente evitado, pois isso só iria adiar a mesma perturbação para a próxima versão. Cada cliente afetado foi desbloqueado através do registro de URL ACS, e estamos trabalhando com Okta para tornar a validação de URL ACS condicional novamente, para que instâncias sem URLs ACS adicionais configuradas se comportem exatamente como antes e nenhuma ação do cliente é necessária. # 5. Itens de Ação Para evitar que estas questões voltem a acontecer, estamos a trabalhar Itens de acção** --- --- □ Trabalhar com Okta para restaurar a validação de URL ACS condicional, então instâncias sem URLs ACS adicionais configuradas se comportam exatamente como antes e nenhuma ação do cliente é necessária. □ Publique um guia de configuração dedicado para o aplicativo Harness OIN na documentação Harness, incluindo os requisitos de resposta \(ACS\) URL. Adicionar um passo de verificação pré-lançamento independente contra configurações de clientes existentes para qualquer atualização futura para o aplicativo Okta publicado, juntamente com a própria revisão da Okta. □ Migrar a autenticação do usuário para Harness ID, que remove a dependência deste comportamento de validação inteiramente. □

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Gwengolo 2026 da 18:45 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 29 Gwengolo 2026 da 21:55 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

3. 29 Gwengolo 2026 da 22:01 UTCresolved

   Este incidente foi resolvido.

4. 2 Here 2026 da 22:40 UTCpostmortem

   Resumo Entre aproximadamente **11:37 AM e 3:01 PM PDT \(18:37–22:01 UTC\) em 29 de setembro de 2026**, os clientes usando o Harness CI auto-hosted Linux cloud runners em **prod1/prod2 \(us-west1\)** experimentaram falhas intermitentes de rede durante a execução do oleoduto — principalmente o tempo de espera Git/network ao buscar o código fonte. **Root Cause** Isto foi principalmente devido à saturação do nosso NAT que foi mais exacerbado por um provedor de nuvem temporária capacidade de computação, impedindo o novo provisionamento de VM lá. Impacto * Os clientes executando auto-hosted Linux CI builds in us-west1 viu ** intermittent build/pipeline failures**, not a full outage. * Erros observados para o cliente incluídos Git fetch timeouts, por exemplo `Falhou em se conectar à porta github.com 443: Tempo de conexão esgotado` **Remediação** * ** Imediato:** Reequilibrada carga ARM build-VM do caminho saturado us-west1 para central1 \(parcialmente limitado pela capacidade central1\); reiniciado os gateways NAT da nuvem afetada, que estabilizavam a rede de tubulação. ** Itens de Acção ** 1. Segurança adicional NAT gateway / capacidade IP \ (em progresso\) 2. Melhorar a detecção de saturação NAT e alertar à frente do impacto do cliente. 3. Avaliar contingências de capacidade entre regiões para que a escassez de computação de uma única região não bloqueie a mitigação do failover.

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Gwengolo 2026 da 14:41 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 29 Gwengolo 2026 da 15:54 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

3. 29 Gwengolo 2026 da 15:57 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

4. 29 Gwengolo 2026 da 18:49 UTCresolved

   Este incidente foi resolvido.

5. 2 Here 2026 da 05:37 UTCpostmortem

   **Resumo** Clientes no Prod-2 experimentaram elevadas taxas de falha em tubulações de verificação contínua. Os trabalhos de verificação não completaram ou reportaram erros porque os trabalhadores de coleta de dados CV não puderam se comunicar com o serviço de plataforma que coordena seu trabalho. Isto foi causado por um inesperado pico de tráfego num dos nossos sistemas de infra-estrutura. O serviço foi restaurado através da ampliação do componente da plataforma afetada. Nenhuma perda de dados ou corrupção ocorreu. □ ** Impacto do cliente ** Os clientes que usam a Verificação Contínua no Prod-2 viram os trabalhos do oleoduto de verificação falharem ou o tempo passar durante a janela do incidente. Uma fração significativa das instâncias de trabalho de verificação que decorreu durante este período terminou em uma falha operacional. As condutas que não utilizavam CV continuaram a funcionar normalmente. □ **Root Cause** Uma grande execução de provisionamento automatizado criou um número significativo de trabalhadores persistentes de monitoramento de CV em uma janela curta, que oprimiu um componente de plataforma compartilhada. O aumento súbito das chamadas de saída simultâneas esgotou as conexões de rede disponíveis em cada instância de serviço. □ **Mitigação** O limite máximo de escala para o serviço CV foi elevado, permitindo-lhe ampliar a capacidade de atender à demanda. Os fracassos pararam pouco tempo após o escalonamento ter sido concluído. □ **Próximos Passos Para evitar a recorrência, Harness irá: * ** Aumentar a capacidade da cabeceira e adicionar guarnições de provisionamento:** Elevar o limite de escala de serviço CV para manter a sala de cabeceira sob cargas de ruptura, e introduzir limitação de taxa para o fornecimento a granel de serviços monitorados. * **Melhorar a resiliência:** Adicione backoff exponencial e jitter para repetições de trabalhadores, e use um pool de conexão reutilizável para reduzir sobrecarga e evitar falhas transitórias de compostos sob alta concorrência. * **Melhorar a monitorização e o alerta: ** Melhorar o alerta para taxas de crescimento anormal por conta do trabalhador, de modo que condições semelhantes são detectadas e agidas anteriormente.

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Gwengolo 2026 da 13:12 UTCresolved

   Em 28 de setembro de 2026, observamos um problema com a cópia de arquivos da Harness Filestore durante a etapa de exportação, onde os arquivos estavam sendo copiados como arquivos nulos/vazios. Como resultado, todos os pipelines usando APIs Filestore foram bloqueados durante a janela incidente. O problema foi causado devido a um lançamento da Bandeira de Característica que foi revertida uma vez que o problema foi descoberto. Todas as operações voltaram ao normal.

2. 1 Here 2026 da 17:28 UTCpostmortem

   Resumo Em 28 de setembro de 2026, alguns clientes no Prod-2 experimentaram falhas em etapas de pipeline de CD que leram o conteúdo do File Store usando expressões de pipeline \(ex., ` `\). As expressões afetadas retornaram nulas em vez do conteúdo esperado do arquivo, fazendo com que as etapas dependentes falhassem ou se comportassem incorretamente. A questão foi rastreada para uma atualização de plataforma que apertou as verificações de autorização em APIs de loja de arquivos. A atualização foi revirada, e as expressões File Store têm funcionado normalmente desde então. # # Impacto do Cliente * Apenas passos pipeline no Prod-2 que leram o conteúdo da Loja de Arquivos através de expressões foram afetados. Pipelines que não usam expressões File Store não foram impactadas. * Expressões afetadas resolvidas para null, causando passos que dependem da configuração ou arquivos de configurações para falhar ou produzir saída incorreta. * Nenhum conteúdo do File Store foi modificado. Nenhum arquivo, segredos, credenciais ou artefatos foram expostos, e nenhum dado foi perdido. Causa raiz Como parte de uma iniciativa de segurança contínua, Harness implantou verificações de autorização mais rigorosas em várias APIs de plataforma, incluindo a API que serve conteúdo da Loja de Arquivos. Quando um pipeline avalia uma expressão File Store, um serviço interno de Harness chama outro para recuperar o arquivo. As novas verificações de autorização falharam, resultando na rejeição dos pedidos e no retorno das expressões nulas. Mitigação Uma vez que a atualização da plataforma foi identificada como a causa, ela foi rolada para trás em todo o ambiente de produção. As expressões File Store foram resolvidas corretamente desde o rollback. Nenhuma ação do cliente é necessária. ## # Medidas Preventivas e Próximos Passos * **Auditar APIs afetadas:** Reveja todas as APIs onde os controlos de autorização mais rigorosos foram aplicados para garantir que as chamadas internas de serviço a serviço são corretamente contabilizadas. * **Melhorar a cobertura do teste:** Melhore as suítes de teste automatizadas para incluir a avaliação de expressão do File Store nos caminhos de execução do pipeline

Traduzido automaticamente da atualização oficial do incidente.

1. 23 Gwengolo 2026 da 20:17 UTCinvestigating

   Atualmente estamos investigando problemas de conectividade que afetam clientes cujos ambientes estão protegidos por firewalls da Palo Alto Networks. Esses firewalls estão bloqueando conexões com as APIs Harness, o que pode resultar em: - Execuções falhadas do gasoduto - Incapacidade de implantar aplicações - Tempo limite intermitente ao acessar recursos da plataforma Harness - Falhas de integração com ferramentas de terceiros - Delegado conectividade com a plataforma Harness Este problema não é causado por uma falha no serviço Harness, mas sim por regras de firewall do seu lado da rede. Estamos aconselhando os clientes a abrir uma exceção para nossos terminais DNS.

2. 24 Gwengolo 2026 da 08:43 UTCmonitoring

   Mitigação disponível: tráfego de carga bloqueado pela política de segurança da rede Identificamos um problema em que alguns clientes podem não conseguir acessar o Harness porque o tráfego do Harness está sendo categorizado como “AI-Platform” por controles de segurança da rede Palo Alto e posteriormente bloqueado pela política firewall/INET do cliente. Se você está experimentando este problema: Entre em contato com a equipe Network/Firewall/CyberSecurity da sua organização e peça que o tráfego necessário do Harness seja permitido através de sua política de firewall Palo Alto. Como mitigação, os clientes podem permitir a categoria de URL “AI-Platform” para os endpoints de Harness necessários, ou adicionar os domínios de Harness/FQDNs afetados à lista aprovada/permissão de sua organização, de acordo com suas políticas de segurança. Após a atualização da política de firewall, o acesso ao Harness deve ser restaurado. Importante: A política de firewall é gerenciada pela equipe de segurança/rede do cliente. Se o endpoint Harness for incorretamente categorizado por Palo Alto, os clientes também podem solicitar uma revisão de URL-categoria de Palo Alto Networks.

3. 25 Gwengolo 2026 da 17:10 UTCresolved

   Após consulta com a Palo Alto Networks, podemos confirmar que no dia 23 de setembro de 2026, app.harness. io foi categorizado como um serviço de plataforma de IA pela Equipe de Redes Palo Alto. A Palo Alto Networks enviou um aviso aos clientes em agosto sobre a reclassificação. Esta alteração pode colocar o AI Platform Service numa política diferente da app.harness. io's anterior governset categorization, Computer and Internet Info. A política aplicada depende das configurações do cliente. Os clientes devem discutir esta categorização e os alertas com sua equipe de rede interna e Palo Alto Networks.

4. 13 Here 2026 da 04:50 UTCpostmortem

   .

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Gwengolo 2026 da 16:40 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 22 Gwengolo 2026 da 17:14 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 22 Gwengolo 2026 da 18:01 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 22 Gwengolo 2026 da 18:38 UTCresolved

   Este incidente foi resolvido.

5. 2 Here 2026 da 22:05 UTCpostmortem

   Resumo Em 22 de setembro de 2026, três de nossas entradas de rede de saída em uma região ficaram insalubres e começaram a rejeitar uma pequena porcentagem de novas tentativas de conexão de saída. O problema foi resolvido no mesmo dia problema completamente sem mais recorrência ou impacto de seguimento. A causa subjacente foi um saturado tampão interno de monitoramento de tráfego nesses gateways, o que fez com que seus controles de saúde respondessem muito lentamente e ficassem marcados como não saudáveis. Impacto * Apenas três instâncias de gateway em uma região foram afetadas; outras regiões e outros gateways na mesma região não foram impactados. * Não houve falha em cascata, o problema foi totalmente resolvido com uma única rodada de reinícios de gateway, e nenhum problema de continuação ocorreu depois. Causa raiz Nossos gateways de rede de saída executam um componente interno que monitora o tráfego de rede para visibilidade operacional. Sob alto tráfego sustentado, o buffer interno deste componente ficou saturado, o que criou uma contrapressão suficientemente grave para retardar as respostas de verificação de saúde do próprio gateway além do tempo que nosso balanceador de carga permite. Uma vez ultrapassado esse tempo, o balanceador de carga marcou os gateways afetados não saudáveis e começou a rejeitar uma porção de novas conexões destinadas a eles. O real encaminhamento de pacotes continuou a funcionar normalmente durante todo o incidente. Este foi especificamente um problema de verificação de saúde e monitoramento-buffer, não uma falha da capacidade de encaminhamento do núcleo dos gateways. Resolução As três instâncias de gateway afetadas foram reiniciadas manualmente, o que limpou o buffer de monitoramento saturado e restaurou imediatamente o comportamento normal de verificação de saúde. Rejeições de conexão pararam assim que o reinício foi concluído, e não foi necessária mais intervenção. # Ações Preventivas Action** --- --- Substituir a atual abordagem de monitoramento de tráfego em todos os gateways por uma implementação mais eficiente e de cabeça baixa que não pode saturar desta forma, e que alerta bem antes de qualquer impacto visível pelo cliente. □ Implemente a substituição automática e periódica de instâncias de gateway de longo prazo em um cronograma fixo, para que nenhuma instância possa acumular o tipo de degradação relacionada à idade observada neste incidente. □ □ Migrar instâncias de gateway para infraestrutura otimizada em rede com capacidade de rede substancialmente mais dedicada, mais adequada para o tráfego sustentado de alto rendimento. Melhorar a utilização do buffer de monitoramento existente enquanto a substituição de longo prazo é implementada. □ Melhorar o alerta específico sobre a latência da resposta de verificação de saúde do gateway, para captar sinais precoces de degradação antes de se tornar visível pelo cliente. □

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Gwengolo 2026 da 14:00 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

2. 22 Gwengolo 2026 da 14:08 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

3. 22 Gwengolo 2026 da 14:20 UTCresolved

   Este incidente foi resolvido.

4. 2 Here 2026 da 22:10 UTCpostmortem

   O mesmo que a causa da raiz anterior.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Gwengolo 2026 da 16:39 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 21 Gwengolo 2026 da 17:12 UTCidentified

   A questão foi identificada e está a ser implementada uma solução.

3. 21 Gwengolo 2026 da 18:27 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

4. 21 Gwengolo 2026 da 18:33 UTCresolved

   Este incidente foi resolvido.

5. 29 Gwengolo 2026 da 22:39 UTCpostmortem

   # # Resumo Em 21 de setembro de 2026, os clientes da Prod 2 experimentaram painéis de implantação degradados e em grande parte indisponível por aproximadamente três horas. O problema foi causado por um conjunto de consultas analíticas por trás desses painéis lendo muito mais dados do que eles precisavam, que esgotaram a capacidade do banco de dados que os servia. Uma reinicialização dos painéis totalmente restaurados do serviço afetado, e a plataforma tem sido estável desde então. # # Impacto do Cliente Páginas do painel carregadas lentamente ou cronometradas entre 14:48 e 18:11 UTC. O registro de execução e implantação de tubulação é executado em infraestrutura separada e continuou a funcionar normalmente. Nenhuma perda de dados ou corrupção ocorreu. # # Causa raiz As consultas no painel estavam faltando um filtro de intervalo de tempo na coluna usada para dividir a maior tabela em segmentos semanais, então cada consulta leu todos os dados históricos em vez de apenas o período solicitado. A correção nunca foi afetada — os painéis retornaram os resultados certos; apenas a quantidade de dados lidos para produzi-los foi excessiva. À medida que o volume de dados crescia, o custo dessas leituras excedeu o que o banco de dados poderia servir, e as tentativas de falhas adicionaram mais carga, de modo que a condição não ficou clara até que o serviço fosse reiniciado. # # Mitigação * Efetuou um rolling reinício do serviço afetado, que parou o ciclo de repetição e permitiu que o banco de dados para completar o seu excelente trabalho * Latência confirmada do painel e uso da conexão do banco de dados retornou aos níveis normais # # Próximos Passos Para evitar a recorrência, Harness irá: * Adicione o filtro de intervalo de tempo faltando para as consultas do painel afetado para que cada leitura apenas o período solicitado * Substituir as tentativas imediatas com as tentativas limitadas e de backup * Melhorar a detecção adicionando alertas sobre o uso da conexão de banco de dados e custo de execução por consulta

Traduzido automaticamente da atualização oficial do incidente.