O Prod2 estava intermitentemente indisponível
Pending
Componentes afetados
Platform
- investigating
Estamos actualmente a investigar esta questão.
- resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
82 Split incidents · Ebrel 2026 — official updates, affected components, duration and resolution details.
Estamos actualmente a investigar esta questão.
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
A execução da tubulação está presa no Prod1. Estamos a investigar a questão.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
# # Resumo Entre 27 de agosto e 28 de agosto de 2026, os clientes experimentaram um problema onde alguns pipelines, implantações e recursos relacionados apareceram como não encontrados na interface Harness e API, embora os dados subjacentes permanecessem intactos. □ O problema ocorreu durante uma atualização de infraestrutura interna planejada que afetou a comunicação entre serviços de plataforma interna. Como resultado, as solicitações que dependiam da conta, organização e resolução do escopo do projeto não foram capazes de completar com sucesso, o que levou a respostas incorretas não encontradas sendo devolvidas aos clientes para entidades existentes. □ A Engenharia identificou o problema, recuou a mudança e restaurou o serviço normal. Nenhum dado do cliente foi perdido ou excluído durante o incidente. □ # # Causa raiz O problema foi causado por um erro de configuração introduzido durante uma atualização de roteamento de serviço interno planejado na produção. Um serviço de plataforma interna responsável pela resolução de contas, organização e contexto do projeto não pôde validar solicitações de outros serviços do Harness após a alteração ser aplicada. Como essa etapa de validação é necessária antes que muitas entidades leiam e ações relacionadas com o pipeline possam prosseguir, as solicitações falhadas surgiram para os clientes como erros não encontrados para os recursos que continuaram a existir normalmente. A questão foi limitada ao ambiente de produção afetado e foi resolvida revertendo a mudança e restabelecendo o caminho de comunicação do serviço anterior. □ # # Impacto * Alguns clientes viram pipelines existentes, implantações e entidades relacionadas aparecer como não encontrado na UI e API. * Algumas operações relacionadas ao oleoduto, incluindo progressão de execução, partidas com gatilho webhook, avaliação de gatilho programada e listagem de entidades, foram temporariamente interrompidas. * O problema afetou a disponibilidade e visibilidade das entidades existentes, mas ele não removeu dados ou alterar configurações do cliente. * Nenhum acesso não autorizado ocorreu, e nenhuma perda de dados do cliente foi observada. # # Remediação * **Imediato:** Reverteu a atualização da configuração da infraestrutura e restaurou o caminho de comunicação de serviço que já estava funcionando. * Validação da recuperação:** Verifiquei que as buscas de entidades afetadas, operações de pipeline e APIs dependentes estavam funcionando normalmente após o rollback. * **Permanente:** Corrigimos o tratamento de configuração associado à atualização para que problemas semelhantes não interfiram com a autenticação serviço-serviço em futuras implementações. # # Itens de Ação Para evitar que tais questões aconteçam novamente, Harness irá 1. Melhorar a validação de configuração, melhorando os testes de pré- implantação para verificar a comunicação interna de serviços antes de deslocar o tráfego de produção. 2. Melhore o monitoramento e alerta para falhas de autenticação interna para que os problemas possam ser detectados mais cedo. 3. Melhorar o tratamento de erros assim que falhas de dependência são menos prováveis de aparecer aos clientes como recurso não encontrado erros.
Traduzido automaticamente da atualização oficial do incidente.
Estamos atualmente investigando uma questão relatada em gasodutos IACM em clusters Prod-1 , Prod-2 ,Prod-4 e EU1.
Continuamos a investigar esta questão.
Revertemos a mudança que causou esta questão em todos os clusters.
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
Atualmente estamos investigando relatórios de que a interface de usuário Gestão de Recursos e Experimentação (FME) está falhando em carregar. Os clientes que tentam acessar o console FME podem encontrar erros ou páginas sem resposta. Não se acredita que a avaliação da bandeira de recurso e o tráfego SDK sejam afetados. Em breve, seguir-se-á uma nova actualização.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
# # Resumo * A partir de **23:42 UTC** em 23 de agosto de 2026, vários clientes da FME relataram falhas no carregamento da FME UI. * Artefatos FME UI servidos do CDN expiraram devido a uma política de retenção, fazendo com que o FME UI não carregasse. * Qualquer solicitação de bandeira muda através da API, mudança de entrega e o pipeline de dados continuou a funcionar sem interrupção. # # Causa raiz * O FME UI é servido a partir de um CDN. Os artefatos da UI foram despejados devido a uma política de retenção, fazendo com que a UI não carregasse para todos os usuários. # # Impacto * A interface FME não foi capaz de carregar para todos os usuários em todos os ambientes de produção. # # # O que não foi impactado? * Avaliação da funcionalidade SDK e da bandeira de execução * Chamadas de API do administrador * Dados de configuração da bandeira do cliente * Nenhuma perda de dados ocorreu # # Remediação * FME UI foi restaurado no CDN através de uma implantação * Recuperação confirmada em todos os ambientes de produção antes de fechar o incidente. # # Itens de Ação * Melhorar a política de retenção de ativos para que a versão atualmente ativa nunca esteja sujeita ao despejo.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A lentidão pode causar qualquer um dos sintomas abaixo: - Pipelines não iniciados - Atrasos na execução - Pipelines sendo canceladas devido a tempo limite
Nosso provedor de nuvem está enfrentando um incidente ativo e estamos acompanhando.
Continuamos a investigar esta questão.
Nosso provedor de nuvem confirmou um incidente contínuo impactando várias regiões. Os oleodutos Harness não experimentaram falhas como resultado, embora alguns usuários possam continuar a experimentar lentidão. Estamos acompanhando de perto a situação e forneceremos atualizações à medida que mais informações estiverem disponíveis.
Estamos observando latências melhoradas em todos os sentidos seguindo a correção implementada pelo nosso provedor de nuvem. Continuamos a acompanhar de perto a situação e forneceremos mais actualizações, tal como se justifica. Observamos algumas execuções para CI para alguns clientes, que estamos investigando
Este incidente foi resolvido.
Resumo Em 20 de agosto de 2026, com início em aproximadamente 15:00 UTC, a plataforma Harness experimentou degradação generalizada do desempenho em todos os ambientes de produção. As execuções pipeline que normalmente terminam em cerca de dois minutos levaram sete a dez minutos. Entrega Contínua, Integração Contínua, orquestração de tubulações e Gestão de Recursos e Experimentação foram todos afetados. O Google Cloud Platform teve um incidente multiproduto na região us-west1 afetando Bigtable, Compute Engine, Google Kubernetes Engine e I/O de disco persistente. A infraestrutura de produção Harness é executada em discos persistentes nessa região. A degradação aumentou a latência da operação do banco de dados de aproximadamente 2 ms a mais de 10 ms no percentil 95, o que, por sua vez, causou defasagem no processamento de mensagens e filas e se propagou para cada serviço que depende do acesso oportuno ao banco de dados. □ Impacto Isto foi uma degradação, não uma interrupção. Pipelines continuaram a executar e completar com sucesso durante todo; eles foram lentos ao invés de falhar. Nenhum dado foi perdido, e nenhum trabalho do cliente foi abandonado como resultado deste incidente. # ** Causa da raiz** A infraestrutura de produção de Harness nos ambientes afetados é executada na Google Cloud Platform discos persistentes na região us-west1. Quando essa camada de armazenamento se degradava, o efeito propagava-se através da plataforma numa cadeia previsível: **Degradação de E/S persistente em us-west1. O Google Cloud Platform experimentou um incidente multiproduto afetando Bigtable, Compute Engine, Google Kubernetes Engine e desempenho de disco persistente. Foi uma falha de infraestrutura no ambiente do provedor, fora do controle de Harness. **Acções preventivas** Embora o Harness não possa impedir uma falha na infraestrutura do provedor de nuvem. As ações abaixo visam detectar uma mais rápida e melhor posicionada para atuar sobre ela. Action** --- --- Continuar o pré-teste de rotina de failovers de banco de dados trans-região alvo, tal como realizado durante este incidente, para manter a prontidão de failover verificada em vez de assumir • Avaliar a disponibilidade de failover multi-regiões para cenários futuros em que a latência inter-regional seria inaceitável
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
Resumo Em 20 de agosto de 2026, entre 10:24 e 14:55 UTC, um subconjunto de FME escreve falhou. As escritas feitas a partir da interface FME e as escritas feitas com tokens de acesso Harness \(PATs e SATs\) não foram afetadas. A avaliação da bandeira de execução continuou a funcionar normalmente. O problema foi mitigado revertendo uma recente mudança de autenticação em um serviço de governança compartilhada, e os escritos afetados retornaram ao normal às 14:55 UTC. Estado: [https://status.harness.io/incidentes/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) Causa raiz Uma mudança na forma como um serviço de governança compartilhada autenticou chamadas de entrada resultou em algumas mensagens FME serem rejeitadas. Esses escrevem credenciais de serviço a serviço usadas que o serviço de governança não poderia mais verificar após a mudança. A FME enfrenta uma falha de governança para o cliente como HTTP 499, o mesmo status usado quando uma política de governança nega intencionalmente uma mudança. Como 499 é uma resposta válida e esperada nesse caminho de negação, as falhas não pareciam uma falha em nossos alertas, e o incidente foi identificado a partir de relatórios de clientes em vez de detecção interna. Impacto * Um subconjunto de FME escreve falhou durante a janela, principalmente aqueles feitos usando chaves legado Split API ou mudar agendamento de pedidos. * As escritas feitas da interface FME não foram impactadas. * As gravações usando tokens de acesso de Harness \(PATs e SATs\) não foram impactadas. * A avaliação da bandeira do Runtime continuou normalmente. * Não houve perda de dados. Erro ao escrever não se aplica. □ Remediação Reverteu a alteração de autenticação do serviço de governança. Escreves afetados voltaram ao normal imediatamente. Itens de Ação Para evitar que tais questões voltem a acontecer, * Harness retornará um erro distinto \(não 499\) quando uma escrita falhar porque a governança não pode ser avaliada, então não é confundida com uma negação intencional da política. * Adicione alerta sobre a própria avaliação de governança, em vez de confiar no código de status voltado para o cliente. * Expandir o suporte de autenticação para avaliações de políticas. * Expandir a cobertura automatizada para cenários de gravação adicionais.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
Continuamos a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Continuamos monitorando quaisquer outros problemas.
Este incidente foi resolvido.
**Resumo** Em 19 de agosto de 2026, entre 12:35 e 17:29 UTC, o serviço Harness Application Security sofreu uma perturbação significativa que afetou tanto o console voltado para o cliente quanto o pipeline de ingestão de dados nas regiões SaaS Production e US1. □ **Root Cause** O serviço de configuração interna que fornece configurações de tempo de execução para quase todos os outros componentes tornou-se sobrecarregado e entrou em um ciclo de reinício repetido. Como muitos serviços dependem disso, os efeitos foram amplos: páginas de console, como políticas de proteção, visualizações de postura, registros de atividade, inventário de API e política personalizada não conseguiram carregar ou cronometrar, e o processamento a jusante parou enquanto esperavam pela configuração que não pudesse obter. ** Impacto do cliente ** * Dimensão** --- --- --- --- O impacto do console \(UI\) Não foi possível carregar ou cronometrar várias páginas, incluindo políticas de proteção, páginas de eventos de postura e visualizações de postura dentro de painéis e páginas de insight, consultas de log de atividade, telas de inventário de API, política personalizada e visualizações de dados sensíveis e widgets. □ □ Impacto da ingestão; O processamento da telemetria de segurança degradou-se severamente e, em alguns caminhos, parou completamente. A defasagem do consumidor cresceu através da normalização, agrupamento, detecção de anomalias, geração e fases de processamento relacionadas. □ Perda de dados Um subconjunto de telemetria ingerido durante a interrupção foi permanentemente abandonado. □ □ **Mitigação** Várias mitigações intermediárias CPU e memória adicional, limiares de verificação de saúde relaxados, um banco de dados reiniciado, e um pool de conexão maior melhorou o problema. Desactivando a nova funcionalidade em ambas as regiões afectadas, restaurou o rendimento de forma acentuada e duradoura. O incidente foi resolvido às 17:29 UTC. □ **Acções preventivas** As seguintes ações são comprometidas e monitoradas internamente até a conclusão. A funcionalidade que desencadeou este incidente permanece desactivada e não será reactivada até que o trabalho abaixo esteja completo e validado. Action** --- --- . . Otimizar o código, afinando parâmetros, tais como despejo de cache e retenção , avaliar paginação baseada em cursor para recuperação de regra em massa como contagens de regra crescer Adicionar um índice de banco de dados para o padrão de acesso de serviço Remediar semântica de recuperação de pipeline para que os consumidores replay com segurança após a perda do marcador de posição em vez de pular backlog □ Mandate staged rollout para sobreposições de configuração que alteram os padrões de requisição a jusante: cluster de baixo volume, em seguida, volume médio, em seguida, volume alto Adicionar contrapressão e proteção de concorrência ao serviço de configuração: quebra de circuito, filas delimitadas e isolamento de tempo limite Melhorar a observabilidade através da instrumentação de métricas mais detalhadas
Traduzido automaticamente da atualização oficial do incidente.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Estamos a monitorizar os oleodutos encravados no prod2. As novas execuções estão passando, pois estamos monitorando continuamente os serviços.
Estamos a monitorizar os oleodutos encravados no prod2. Para os clientes que ainda estão vendo oleodutos presos, solicitamos que você aborte e reative.
Este incidente foi resolvido.
## **Resumo # Em 6 de agosto de 2026 \(de manhã PDT\), alguns clientes executando pipelines no ambiente de produção Prod2 observaram execuções de pipeline que pararam de fazer progresso - etapas que não avançaram e não produziram mais atualizações de saída ou status. O problema foi relatado por clientes afetados. Os engenheiros do Harness identificaram a causa, mitigou o impacto, e as execuções do gasoduto retornaram à operação normal. A questão foi causada por uma expressão auto-referencial. Um git webhook desencadeou um pipeline que referenciava o conteúdo da carga útil do webhook, e o próprio payload continha mais cópias dessa mesma expressão. Cada rodada de resolução de expressão, portanto, produziu mais expressões para resolver, dobrando a quantidade de trabalho cada vez. Isso esgotou os recursos da instância de serviço processando aquela execução, e outras execuções atribuídas à mesma instância não foram capazes de progredir enquanto ela estava nesse estado. ## **Impacto# Durante a janela incidente \(aproximadamente 6:11 a 11:23 PDT AM em 6 de agosto de 2026\): * As execuções de pipeline de alguns clientes no Prod2 pararam no meio da execução e não fizeram mais nenhum progresso. * As execuções afetadas não produziram nenhuma nova saída de passo ou atualizações de status, e tiveram que ser abortadas e re-run após mitigação. * Comportamento foi limitado às execuções sendo processadas pela instância de serviço afetada — pipelines manipulados por outras instâncias continuaram a executar normalmente. Não houve ** perda de dados**. Definições de pipeline, histórico de execução e estado armazenado não foram afetados. A maioria dos oleodutos no Prod2 continuou a executar com sucesso durante todo o incidente; o impacto principal foi que algumas execuções em voo não puderam completar e precisavam ser re-run uma vez que o problema foi atenuado. # # ** Causa da raiz # Os pipelines Harness suportam expressões que são resolvidas em tempo de execução — por exemplo, uma expressão que insere o conteúdo da carga útil do Git webhook que desencadeou o pipeline. Neste caso, uma mensagem Git commit continha o texto literal da expressão de carga útil em si, duas vezes, e o pipeline referenciava essa mesma expressão de carga útil. Como a mensagem de commit faz parte da carga útil do webhook, resolver a expressão inseriu toda a carga útil — incluindo as duas cópias literais da expressão transportada na mensagem de commit. Essas cópias recentemente inseridas foram então tratadas como expressões a serem resolvidas, e cada passagem inseriu mais duas cópias completas da carga útil. O tamanho do valor sendo processado, e o trabalho necessário para processá-lo, por isso dobrou em cada passagem e cresceu exponencialmente em vez de convergir. Harness tem uma salvaguarda destinada a parar exatamente isso: a resolução da expressão é limitada por uma profundidade máxima de nidificação, além da qual a resolução pára e o gasoduto falha com um erro explícito. Um defeito nessa salvaguarda significava que o limite não era aplicado neste caso específico de auto-referenciamento, pelo que a resolução continuou descontrolada. A resolução da expressão é executada em linha nos threads que iniciam os passos do pipeline. À medida que cada passo consumia progressivamente mais memória e CPU sem nunca completar, a instância de serviço que realizava esse trabalho parou de fazer progresso, e cada execução atribuída a essa instância parou — que foi o que os clientes relataram. # # **Mitigação # Harness completou as seguintes etapas de mitigação imediata: * Identificado o pipeline e o padrão de expressão responsável pela resolução de fuga. * Parou a instância de serviço afetada para que não assumisse mais nenhum trabalho. As restantes instâncias saudáveis captaram e processaram as execuções em fila normalmente. * Confirmado que as execuções do gasoduto retornaram ao normal e fechou o incidente. Essas ações restauraram o comportamento normal de execução de dutos e resolveram o impacto voltado para o cliente. ## **Itens de ação Para reduzir o risco de recorrência e melhorar a detecção, as seguintes ações estão em várias etapas de implementação: * Corrigir o defeito na expressão profundidade e loop-detecção salvaguarda para que as expressões auto-referenciais são capturadas e falhar rapidamente com um erro claro em vez de consumir recursos sem limite. * Impedir que expressões de carga útil sejam resolvidas fora do conteúdo de carga útil do gatilho, removendo completamente o caminho autorreferencial. * Apertar a profundidade máxima de aninhamento de expressão e avaliar a detecção explícita de laço, além do limite de profundidade existente. * Melhorar testes automatizados em ambientes de pré-produção que reproduzem padrões de expressão autorreferenciais e verificam se a proteção os detecta e os para. * Adicione monitoramento para este padrão em execuções de pipeline para que seja detectado proativamente.
Traduzido automaticamente da atualização oficial do incidente.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
Estamos actualmente a investigar esta questão.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
**Resumo** Entre 25 de julho e 4 de agosto de 2026, painéis de execução de pipeline e páginas de visão geral nos clusters Harness Prod 2 e Prod 3 exibiram dados que estavam entre o tempo real. Os próprios pipelines continuaram a construir, implantar e executar normalmente durante todo o processo; o problema foi confinado à rapidez com que os registros de execução foram copiados para o banco de dados que serve relatórios e visualizações do painel. □ ** Nenhum dado do cliente foi perdido.** Cada registro afetado permaneceu duravelmente armazenado e foi reproduzido no datastore de análise uma vez que a limitação subjacente foi removida. Harness migrou os clusters afetados para uma versão horizontalmente escalonável e apoiada na fila do componente de replicação em 1 de agosto de 2026 e completou os backfills de dados direcionados para todas as contas afetadas. # ** Causa da raiz** O Harness mantém um componente de captura de dados de mudança que replica continuamente os registros de execução de pipeline da loja de dados operacional primária em uma loja de dados de série temporal separada otimizada para painéis e pesquisas de relatórios. Dashboards ler exclusivamente a partir da datastore de análise. Quando a replicação fica para trás, os painéis renderizam uma visão precisa mas antiga do mundo, enquanto a execução em si não é afetada. Isso foi causado pelo aumento acentuado e sustentado do volume de gravação de banco de dados de outro módulo da plataforma Harness que compartilhava o mesmo caminho de replicação excedeu o teto de transferência da versão mais antiga e monoinstancial desse componente ainda em execução em Prod 2 e Prod 3. Um atraso se formou e cresceu. □ □ **Acções preventivas** Harness completou ou se comprometeu com as seguintes ações para prevenir tais questões. Action** --- --- □ Ajustar bem o alerta de atraso de replicação de modo a que qualquer atraso para além de um limiar definido seja notificado □ Adicionar um painel de atraso de replicação à placa de monitoramento padrão da plataforma para que a saúde do oleoduto seja visível à disposição por padrão Reduzir a amplificação de gravação de módulos co-tenant através de limitação de taxa por módulo ou filtragem de entidade no fluxo de replicação
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
**Resumo** Em 31 de julho de 2026, uploads de artefatos realizados através de pipeline no cluster EU1 começaram a falhar com um erro de autenticação. Os carregamentos iniciados manualmente \(fora de um pipeline\) não foram afetados, e a capacidade de recuperar artefatos existentes \(downloads\) também não foi afetada — isso foi isolado para o caminho de upload específico do pipeline em um cluster. # **Impacto** * Os uploads de artefatos realizados através de pipeline no cluster EU1 falharam com um erro de autenticação por aproximadamente 4 horas e 34 minutos. * Recuperar artefatos existentes \(downloads\) não foi afetado. * O carregamento manual de artefatos fora de um oleoduto não foi afetado. * Outros clusters/regiões não foram afetados por esta questão. # **Root Cause** O componente responsável pela manipulação de uploads de artefatos baseados em pipeline é distribuído como uma imagem de recipiente. No cluster EU1, essa imagem é recuperada de um registro interno que reflete uma fonte de imagem pública; em outros clusters, a mesma imagem é recuperada diretamente da fonte pública. Um erro de publicação em nosso processo de lançamento fez com que uma nova compilação desse componente fosse publicada usando um label de versão que já estava em uso, ao invés de receber uma nova versão única. Como resultado, duas imagens diferentes acabaram associadas com o mesmo rótulo de versão na fonte pública. Nosso registro interno reflete imagens da fonte pública através de um processo de replicação automatizado. Por causa de como essa replicação foi desencadeada, ele copiou a imagem \(earlier\) original associada com essa legenda de versão em vez da corrigida. Isto significa que o cluster EU1 — que sai do espelho interno — acabou por ter uma imagem diferente e defeituosa do que os outros clusters, que puxam directamente da fonte pública e, por conseguinte, receberam a imagem corrigida. A imagem com defeito continha um problema de autenticação que fez com que os uploads de pipeline falhassem. # **Mitigação** * Reverteu a conta afetada para a última versão conhecida do componente upload, restaurando imediatamente uploads de pipeline. * Publicou uma versão corrigida e permanente do componente para resolver o problema em todos os clusters. **Próximos passos** □ * Corrigir o passo de upload para remover o defeito relacionado ao recipiente subjacente que tornou este modo de falha possível. * Atualizar nosso oleoduto de lançamento para este componente para que a publicação de uma imagem nunca possa sobrescrever uma versão existente — cada publicação deve criar uma nova versão distinta.
Traduzido automaticamente da atualização oficial do incidente.
Resumo - Estamos enfrentando problemas de conectividade de rede intermitentemente com nossa Construir VM incapaz de se conectar a recursos externos. Estamos neste momento a investigar a questão.
Foi implementada uma correção e estamos monitorando os resultados.
Continuamos monitorando quaisquer outros problemas.
Este incidente foi resolvido.
## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
Continuamos a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Continuamos trabalhando em uma solução para esse problema.
Foi implementada uma correção e estamos monitorando os resultados.
Continuamos monitorando quaisquer outros problemas.
Este incidente foi resolvido.
# Summary During a recent production deployment, a defect in our internal deployment tooling caused two critical services to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI. We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom. At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing. # Incident Details ## Incorrect Production Configuration Values Applied Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration. **Root Cause** The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves. **Resolution** Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline. ## Intermittent Login / Access Failures During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window. ## Filestore Access Issue A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment. **Root Cause** This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity. ## Delayed Pipeline Execution Status Updates in UI Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue. **Root Cause** The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally. **Resolution** We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform. # Impact Summary * Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments. * Some users experienced intermittent login or access failures during the affected deployment window. * One customer environment in Prod-3 experienced a filestore access issue. * Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted. # Preventive Actions The following corrective and preventive actions have been identified. | **Corrective / Preventive Action** | | --- | | Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. | | Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. | | Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. | _We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._
Traduzido automaticamente da atualização oficial do incidente.
Estamos investigando um problema impactando painéis AIDI. Os usuários podem experimentar tempos de carga aumentados ou falhas intermitentes ao acessar painéis. Nossa equipe está trabalhando ativamente para identificar a causa raiz e restaurar o desempenho normal. Forneceremos atualizações à medida que mais informações estiverem disponíveis.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
## Summary Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Este incidente foi resolvido.
Resumo Em 17 de julho de 2026, após uma implantação de código de rotina, os clientes em versões mais antigas de delegados \(858xx e abaixo\) começaram a experimentar construções de CI atrasadas em construções hospedadas na Harness Cloud usando nossa capacidade global de compilação. As construções afetadas experimentaram uma pausa inesperada de até aproximadamente 8 minutos na fase "esperando por infraestrutura" antes de continuar, ao invés de prosseguir dentro do tempo sub-segundo esperado. A lentidão global da construção foi intermitente. Impacto * Todas as construções de CI foram potencialmente sujeitas a atraso; o impacto foi mais pronunciado para as construções na infraestrutura hospedada na Harness Cloud usando o recurso global de compilação. * Compilações afetadas experimentaram uma pausa inexplicável de até aproximadamente 8 minutos antes de continuar, seguida por uma "iniciação fria" mais lenta, uma vez que um slot de computação pré-reservado não estava disponível — isso apresentado aos usuários como construções lentas em vez de falhas de construção. * As contas em execução nas versões mais recentes do delegado \(858xx e acima\) não foram impactadas. * Nenhuma compilação falhou diretamente como resultado direto deste problema, e nenhum dado foi perdido. Causa raiz A causa raiz foi uma mudança de código interno que inadvertidamente quebrou como um registro de build-queueing específico foi lido de volta de nosso banco de dados uma vez que compila que já tinha sido em fila na versão anterior do código encontrou a versão recém-implantada. Resolvemos o impacto imediato, limpando os registros afetados e revertendo a alteração de código subjacente, e estamos implementando várias salvaguardas para evitar que essa classe de problema se repita. □ Próximos Passos Avaliamos o risco de uma recorrência semelhante tão baixa quanto as seguintes ações estão sendo realizadas. O caminho de código específico que causou este incidente já foi revertido, e estamos implementando salvaguardas estruturais para que esta classe geral de problema não possa voltar, independentemente de onde na base de códigos possa ocorrer. **Corrective / Preventive Action** --- --- Adicionar identificadores explícitos e estáveis a todas as classes de dados internos que são armazenadas em nosso banco de dados, para que as futuras reorganizações de código interno não possam quebrar a capacidade do sistema de ler registros armazenados anteriormente. □ □ Introduza testes de retrocesso e compatibilidade em nosso ambiente de pré-produção, especificamente projetado para capturar essa classe de problema antes de atingir a produção. □
Traduzido automaticamente da atualização oficial do incidente.
Estamos actualmente a investigar esta questão.
A questão foi identificada e está a ser implementada uma solução.
Foi implementada uma correção e estamos monitorando os resultados.
Continuamos monitorando quaisquer outros problemas.
Este incidente foi resolvido.
Resumo Entre 19 de junho e 17 de julho de 2026, a etapa integrada do Git Clone — e qualquer etapa do pipeline usando o plug-in de clone drone-git — falhou na infraestrutura de construção ARM64 Kubernetes com o erro exec /usr/local/bin/clone: erro de formato exec. AMD64 \(Intel/AMD\) constrói, o Windows constrói, e o caminho binário sem container VM não foi afetado. A causa raiz foi um defeito no nosso processo de publicação de imagens internas que fez com que as imagens de drone-git marcadas com ARM64 realmente contivessem binários AMD64. Identificamos e amenizamos o problema no mesmo dia em que foi relatado revertendo a imagem drone-git para a última versão conhecida-boa. Nenhuma ação do cliente ou mudança de configuração foi necessária. Causa raiz Em 19 de junho de 2026, uma remediação de segurança reestruturou como a imagem drone-git é construída. As compilações AMD64 foram atualizadas corretamente, mas o pipeline de compilação ARM64 não construiu arquivos ARM64 diretamente — ele adaptou o arquivo de compilação AMD64 via substituição de texto e compilou-o na infraestrutura ARM64. A mudança de 19 de junho alterou o arquivo AMD64 de modo que a substituição silenciosamente no-op'd em vez de falhar, então o pipeline publicou uma imagem marcada ARM64 cujos binários Git Clone e Git LFS ainda estavam compilados para AMD64. Impacto * Afetado: O passo integrado do Git Clone, e qualquer passo do pipeline usando o plugin clone drone-git, rodando em ARM64 Kubernetes construir infraestrutura, em todas as contas, entre 6 de julho e 17 de julho de 2026. * Sintom: Compila falha na etapa Git Clone com exec /usr/local/bin/clone: erro de formato exec. * Não afetado: AMD64 \(Intel/AMD\) Kubernetes e VM builds, Windows builds, VM containerless caminho de execução, e nossa variante de imagem endurecida. Mitigação Revertemos a versão de imagem drone-git usada em todos os serviços afetados para a última versão conhecida. Isso resolveu totalmente as falhas de execução do ARM64; não foram necessárias alterações de configuração do cliente. Próximos Passos Para evitar que tais questões aconteçam novamente. * Reconstruir o pipeline de publicação de imagens ARM64 para construir nossos arquivos de compilação dedicados ARM64 diretamente, em vez de adaptar os arquivos de compilação AMD64. * Melhorar a validação pós-publicação automatizada para cada versão da imagem: verificar arquitetura binária corresponde à tag da imagem, e executar um teste de fumaça funcional antes que uma imagem seja considerada lançável. * Expandir a cobertura de teste automatizada para incluir cenários de construção ARM64 Kubernetes. * Remover as versões de imagem intermediárias afetadas da circulação uma vez que a liberação corrigida é validada.
Traduzido automaticamente da atualização oficial do incidente.