A questão foi identificada e está a ser implementada uma solução.
identified
Continuamos trabalhando em uma solução para esse problema.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
### Summary
On September 8, 2026, customers in Prod 1 and Prod 2 experienced elevated platform latency and pipeline failures. The issue was caused by a regression in a newly released capability that triggered cascading failures under high load. Because the capability was behind a feature flag, it was quickly disabled, and service was restored after a brief monitoring period.
### Customer Impact
* Customers encountered slowness and failures during pipeline execution and UI operations. Some API calls returned errors or timed out.
* No data loss or corruption occurred.
### Root Cause
The new capability introduced a regression that created contention on a shared backend resource used by multiple Harness components. This saturated the shared platform infrastructure and caused the cascading failures.
### Mitigation
* Disabled the capability across all environments
* Temporarily increased platform capacity to restore stability
### Next Steps
To prevent recurrence, Harness will:
1. **Permanently fix the capability** by profiling and eliminating the sub-optimal code path and query
2. **Improve detection** by enhancing alerting for resource-intensive queries on high-frequency platform paths
Traduzido automaticamente da atualização oficial do incidente.
O Prod2 estava intermitentemente indisponível
Início 5 Gwengolo 2026 da 09:40 UTC · 1m
Pending
Componentes afetados
Platform
investigating
Estamos actualmente a investigar esta questão.
resolved
Este incidente foi resolvido.
postmortem
## **Summary**
Between 12:34am PST and 12:38am PST on 5th September, the Delegate service manager experienced some elevated exceptions when attempting to write to the database. Consequently, delegate connections were dropped, causing them to disconnect. Delegate automatically re-attempts registration back to the `delegate service manager` and majority of the delegates got connected back after the incident. For Docker and ECS delegates the automatic restart is not enabled unless these delegates have health monitoring enabled. For these delegates a manual restart is needed and was recommended. Post restart the delegate would re-connect and the issue was resolved.
## **Root cause**
On Prod2 cluster we identified a performance bottleneck in the delegate service that, under certain conditions, can increase database write latency and delay heartbeat processing which leads to delegates being disconnected.
## **Impact**
All K8s delegates and \`Docker/ECS\` delegates got connected back immediately within 4 mins and started to function normally. The impact can be scoped to those specific types of delegates that didn’t have health monitoring enabled.
## **Remediation**
* Immediate: We have added additional monitoring and increased resources for handling the influx of traffic.
* Permanent: We have identified a hotspot in the code that can cause high latency when writing to a database which we are actively working on resolving.
## **Action Items**
To prevent such issues from happening again, Harness will work on the following:
1. Increased targeted monitoring and alerting to initiate timely mitigation and prevent this from happening again.
2. Fix the identified delegate service managers database client reconnect failures
3. Fix the hotpots that can cause query latency.
Traduzido automaticamente da atualização oficial do incidente.
Os tubos estão presos no Prod1
Início 3 Gwengolo 2026 da 10:00 UTC · 1h 40m
IssuesMinor incident
Componentes afetados
Continuous Delivery - Next Generation (CDNG)
investigating
A execução da tubulação está presa no Prod1. Estamos a investigar a questão.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Entidades em Harness não estão carregando em Prod3
Início 28 Eost 2026 da 07:04 UTC · 32m
IssuesMinor incident
Componentes afetados
Platform
investigating
Estamos actualmente a investigar esta questão.
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
# # 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.
Pipelines estão falhando para clientes de arnês IACM
Início 26 Eost 2026 da 08:38 UTC · 32m
IssuesMinor incident
Componentes afetados
Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)
investigating
Estamos atualmente investigando uma questão relatada em gasodutos IACM em clusters Prod-1 , Prod-2 ,Prod-4 e EU1.
investigating
Continuamos a investigar esta questão.
monitoring
Revertemos a mudança que causou esta questão em todos os clusters.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Interface de usuário de Gestão e Experimentação de Recursos (FME) indisponível
Início 24 Eost 2026 da 00:57 UTC · 16m
OutageMajor incident
Componentes afetados
FME
investigating
Estamos actualmente a investigar esta questão.
investigating
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.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
# # 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.
Todos os módulos estão sendo lentos no Prod1/2/3/4 devido ao incidente do provedor de nuvem
Início 20 Eost 2026 da 15:37 UTC · 3h 46m
OutageMajor incident
Componentes afetados
PlatformPlatformPlatformPlatform
investigating
Estamos actualmente a investigar esta questão.
investigating
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
investigating
Nosso provedor de nuvem está enfrentando um incidente ativo e estamos acompanhando.
investigating
Continuamos a investigar esta questão.
identified
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.
monitoring
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
resolved
Este incidente foi resolvido.
postmortem
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.
As operações de gravação da API FME começaram a retornar 499 erros
Início 20 Eost 2026 da 14:32 UTC · 30m
IssuesMinor incident
Componentes afetados
FME
investigating
Estamos actualmente a investigar esta questão.
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
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.
A ingestão de dados é adiada na produção rastreável dos EUA
Início 19 Eost 2026 da 13:22 UTC · 2h 44m
OutageMajor incident
Componentes afetados
US - app.traceable.ai / api.traceable.ai
investigating
Estamos actualmente a investigar esta questão.
investigating
Continuamos a investigar esta questão.
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.
monitoring
Continuamos monitorando quaisquer outros problemas.
resolved
Este incidente foi resolvido.
postmortem
**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.
investigating
We are continuing to investigate this issue.
identified
The issue has been identified and a fix is being implemented.
resolved
This incident has been resolved.
postmortem
## 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.
Monitoramento - Pipelines Presos - Prod2
Início 6 Eost 2026 da 13:50 UTC · 4h 31m
IssuesMinor incident
Componentes afetados
Continuous Delivery - Next Generation (CDNG)
monitoring
Estamos a monitorizar os oleodutos encravados no prod2. As novas execuções estão passando, pois estamos monitorando continuamente os serviços.
monitoring
Estamos a monitorizar os oleodutos encravados no prod2. Para os clientes que ainda estão vendo oleodutos presos, solicitamos que você aborte e reative.
resolved
Este incidente foi resolvido.
postmortem
## **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.
Editing 'Variable Sets' in the IaCM module is experiencing issue
Início 4 Eost 2026 da 12:07 UTC · 3h 21m
IssuesMinor incident
Componentes afetados
Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)
investigating
We are currently investigating this issue.
investigating
We are continuing to investigate this issue.
investigating
We have identified the issue and started to implement the fix , prod2 is restored.
investigating
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
investigating
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
resolved
This incident has been resolved.
postmortem
# 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.
Legacy Dashboards - Degradado
Início 3 Eost 2026 da 03:08 UTC · 2h 45m
IssuesMinor incident
Componentes afetados
Custom Dashboards
investigating
Estamos actualmente a investigar esta questão.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Os painéis de interface estão atrasados (CI)
Início 31 Gouere 2026 da 20:22 UTC · 12h 48m
Pending
Componentes afetados
Continuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud BuildsContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud Builds
investigating
Estamos actualmente a investigar esta questão.
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
**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.
O upload do Harness Artifact Registry está falhando no pipeline - região EU1
Início 31 Gouere 2026 da 13:48 UTC · 1d 10h
IssuesMinor incident
Componentes afetados
Artifact Registry
investigating
Estamos actualmente a investigar esta questão.
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
# **Summary**
On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster.
# **Impact**
* Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes.
* Retrieving existing artifacts \(downloads\) was not affected.
* Manually uploading artifacts outside of a pipeline was not affected.
* Other clusters/regions were not affected by this issue.
# **Root Cause**
The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source.
A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source.
Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail.
# **Mitigation**
* Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads.
* Published a corrected, permanent version of the component to resolve the issue across all clusters.
# **Next steps**
* Fix the upload step to remove the underlying container-related defect that made this failure mode possible.
* Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.
Traduzido automaticamente da atualização oficial do incidente.
Problemas de conectividade de rede externa intermitentes que afetam a construção de VMs
Início 30 Gouere 2026 da 05:59 UTC · 21h 24m
IssuesMinor incident
Componentes afetados
Continuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud Builds
investigating
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.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
monitoring
Continuamos monitorando quaisquer outros problemas.
resolved
Este incidente foi resolvido.
postmortem
# # Resumo
A partir de 4 de agosto de 2026, corredores de CI nas regiões us-west1 e us-central1 experimentaram tempo de conexão intermitentemente de aproximadamente 134 segundos ao alcançar serviços externos, como GitHub e Bitbucket sobre gateways de rede de saída.
# # Impacto
* Corredores CI nas regiões afetadas intermitentemente experientes timeouts de conexão de aproximadamente 134 segundos ao atingir serviços externos \(por exemplo, GitHub, Bitbucket\) sobre nossos gateways de rede de saída.
* O problema era intermitente em vez de constante - conexões bem sucedidas sob carga normal, e falhas agrupadas durante períodos de alto volume de tráfego de saída.
* Nenhum dado foi perdido ou corrompido. Tratava-se de uma questão de conectividade e capacidade de rede, não de integridade de dados.
* us-west1 e us-central1 foram as regiões afectadas; outras regiões não foram afectadas por esta questão.
# # Causa raiz
□
Nosso balanceador de carga distribui tráfego de saída através de múltiplos gateways NAT usando um método de hashing baseado em detalhes de conexão \(fonte/endereço de destino e porto\). Para qualquer conexão, esses detalhes permanecem constantes para a vida útil dessa conexão. Tivemos uma onda de tráfego sustentada durante alguns segundos que congestionou os portais.
□
# # Itens de Ação
Para evitar que tais questões voltem a acontecer, Harness irá,
Aumente a capacidade de conexão de saída em nossos gateways NAT fornecendo interfaces de rede externas adicionais, dando a cada gateway um conjunto substancialmente maior de conexões que pode servir simultaneamente.
Traduzido automaticamente da atualização oficial do incidente.
O Prod3 Filestore está a falhar com os erros HTTP 500
Início 27 Gouere 2026 da 09:09 UTC · 4h 24m
OutageMajor incident
Componentes afetados
Continuous Delivery (CD) - FirstGen - EOS
investigating
Estamos actualmente a investigar esta questão.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
O ambiente Prod3 & Prod1 está experimentando interrupções intermitentes. Estamos neste momento a investigar a questão.
A questão foi identificada e está a ser implementada uma solução.
identified
Continuamos trabalhando em uma solução para esse problema.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
monitoring
Continuamos monitorando quaisquer outros problemas.
resolved
Este incidente foi resolvido.
postmortem
# 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.
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
# # Resumo
Os clientes nos clusters Prod1, Prod2 e Prod3 experimentaram falhas intermitentes na carga de widgets e aumentaram o tempo de carga ao acessar os painéis AIDI 2.0 em 22 de julho de 2026. Nem todos os widgets foram afetados simultaneamente o problema manifestado como falhas esporádicas em vez de uma falha total.
Nenhum dado do cliente foi perdido. Os clientes da SEI 1.0 não foram afetados.
# # Causa raiz
Ao longo do tempo, um processo de manutenção de banco de dados de rotina falhou em algumas tabelas em nosso banco de dados de análise, fazendo com que essas tabelas acumulassem um grande volume de metadados internos usados para rastrear registros excluídos. Quando o banco de dados planejou consultas contra essas tabelas, ele carregou todos esses metadados acumulados na memória, fazendo com que o uso da memória nos nós afetados aumentasse repetidamente. Estes picos repetidos desencadearam um mecanismo de segurança automático que reinicia um nó quando detecta pressão excessiva de memória, e os nós afetados começaram a reiniciar em um loop como resultado. Isso causou desempenho de consulta intermitente e degradado em painéis AIDI 2.0 durante a duração do incidente.
# # Impacto
Clientes em clusters Prod1, Prod2 e Prod3 podem ter experimentado falhas intermitentes de carga de widgets ou tempos de carga aumentados em painéis AIDI 2.0.
**Duração:** 22 de julho de 2026, 07:58 PDT - 16:16 PDT \(~8 horas 18 minutos\), com falhas intermitentes de widget; sistema foi reiniciado e sob monitoramento ativo a partir de 08:25 PDT.
# # # O que não foi impactado?
* Ingestão e processamento de dados
* SEI 1.0 clientes
* Integrações e fluxos de metadados
Nenhum dado do cliente foi perdido.
# # Remediação
Ao identificar o problema, os nós do banco de dados afetados foram reiniciados às 08:25 PDT, que restaurou a estabilidade inicial. Continuamos a monitorar de perto o sistema, e quando a degradação intermitente ainda era observada depois, aplicamos várias correções adicionais:
* Configurações de configuração de banco de dados ajustadas para limitar a quantidade de memória usada para processar metadados acumulados, e configurações de planejamento de consultas ajustadas para reduzir a pressão de memória.
* Executar trabalhos de limpeza para reduzir o atraso de metadados acumulados nas tabelas afetadas.
* Aumento da capacidade nos nós de banco de dados afetados para fornecer headroom adicional.
Essas mudanças estabilizaram progressivamente o sistema, e o incidente foi totalmente resolvido em 16:16 PDT.
# # Itens de Ação
Para evitar recorrência, estamos implementando o seguinte:
1. Nós atualizamos a infra-estrutura que inclui melhorias subjacentes que lidam com picos de memória causados por arquivos de exclusão excessiva.
2. Nós rolou para fora trabalhos de compactação automatizada para tabelas recentemente introduzidas para evitar o acúmulo de arquivos de exclusão indo para a frente.
Traduzido automaticamente da atualização oficial do incidente.
Desempenho da IC degradada
Início 17 Gouere 2026 da 17:16 UTC · 4h 40m
IssuesMinor incident
Componentes afetados
Continuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud Builds
investigating
Estamos actualmente a investigar esta questão.
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
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.