Histórico de interrupções do Cycode

1. 27 Here 2026 da 10:06 UTCinvestigating

   **Resumo** Algumas integrações do Bitbucket Cloud que usam o OAuth desconectado após o serviço de autenticação do Bitbucket retornou erros em 27 de outubro de 2026, às 03:45 UTC. **Impacto Para integrações afetadas, o Cycode não pode acessar o Bitbucket. Scans, sincronização do repositório e status de commit para esses espaços de trabalho param até que a integração seja autorizada novamente. As integrações que usam senhas de aplicativos, tokens de API ou tokens de acesso à área de trabalho não são afetadas. ** Última actualização** Nossa investigação mostra que o Bitbucket emitiu novas credenciais para essas integrações, mas não as entregou ao Cycode, porque seu serviço devolveu um erro. O Bitbucket não aceita mais as credenciais anteriores, então as integrações não podem recuperar automaticamente. Estamos a reportar o problema ao Atlassian. ** É necessária uma acção ** Se sua integração com Bitbucket aparecer como desconectada, autorize-a novamente no console Cycode em [Configurações > Integração > Bitbucket]. Cycode continua de onde parou, e nenhuma outra mudança é necessária. Publicaremos uma atualização quando tivermos mais informações.

2. 27 Here 2026 da 10:46 UTCmonitoring

   Identificamos cada integração afetada e agora estamos contatando seus usuários diretamente. Uma integração começa a funcionar novamente assim que seu usuário o autoriza novamente no console Cycode em [Configurações > Integração > Bitbucket]. Relatamos o erro do Bitbucket para o Atlassian e publicaremos uma atualização quando tivermos mais informações.

3. 27 Here 2026 da 12:51 UTCresolved

   Todas as integrações do Bitbucket Cloud afetadas foram identificadas e seus usuários receberam instruções para autorizá-las novamente. Integrações que foram autorizadas novamente funcionam normalmente. A causa raiz foi um erro de serviço Bitbucket em 27 de outubro de 2026, às 03:45 UTC, que invalidaram as credenciais de algumas integrações. Partilhamos os detalhes com a Atlassian para a investigação.

Traduzido automaticamente da atualização oficial do incidente.

1. 20 Here 2026 da 09:28 UTCinvestigating

   Identificamos uma causa potencial dos problemas de fluxo de login e estamos investigando mais.

2. 20 Here 2026 da 09:54 UTCinvestigating

   Resolvemos o problema do fluxo de login na região da UE.

3. 20 Here 2026 da 10:04 UTCmonitoring

   A questão foi resolvida, e continuamos a monitorar o sistema para garantir a estabilidade.

4. 20 Here 2026 da 15:43 UTCresolved

   O incidente foi totalmente resolvido, e não vemos mais questões.

Traduzido automaticamente da atualização oficial do incidente.

1. 18 Here 2026 da 13:10 UTCinvestigating

   Estamos investigando erros na aplicação relacionados à verificação e violação de falhas de carga de RP. Continuaremos a publicar mais actualizações assim que encontrarmos a causa.

2. 18 Here 2026 da 13:26 UTCidentified

   Tivemos um problema com uma das nossas bases de dados de aplicações. A base de dados está de volta às operações normais, mas ainda está degradada, e estamos a trabalhar activamente na sua reparação. A plataforma está de volta às operações normais, e violações e varreduras de RP devem funcionar normalmente.

3. 18 Here 2026 da 13:34 UTCmonitoring

   A base de dados está de volta às operações normais. Estamos a acompanhar activamente para garantir que não subsistem questões.

4. 18 Here 2026 da 14:40 UTCresolved

   O incidente foi totalmente resolvido, e não vemos mais questões.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Here 2026 da 12:56 UTCmonitoring

   ** Monitoramento**: scans API (região dos EUA) Hoje cedo, nosso sistema de alerta detectou que o serviço por trás da API de varredura estava reiniciando com mais frequência do que o esperado, o que fez com que alguns pedidos falhassem por um curto período. Aumentamos a memória disponível para o serviço, e tem sido estável desde então. Estamos mantendo o serviço sob observação, enquanto finalizamos uma melhoria permanente.

2. 13 Here 2026 da 13:01 UTCresolved

   **Resolvido**: Breve desaceleração da API de varredura (região dos EUA) Em 13 de outubro de 2026, entre 07:58 e 08:28 UTC, alguns pedidos para a API scans na região dos EUA falhou ou foram lentos. Analisar páginas na interface Cycode e no Cycode CLI pode ter mostrado erros temporários, e algumas varreduras de solicitação de puxar chegaram alguns minutos depois do normal. Aumentamos a memória disponível para o serviço, que resolveu totalmente o problema às 08:34 UTC. Todas as varreduras em fila completadas pouco depois, e nenhum dado foi perdido. Identificamos a causa e está em revisão uma melhoria permanente.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Here 2026 da 08:30 UTCinvestigating

   O GitLab está passando por uma interrupção de serviço que pode afetar a conectividade de digitalização e integração do Cycode PR. A questão tem origem na infraestrutura do GitLab e está fora do controle do Cycode. Estamos monitorando a situação e vamos fornecer atualizações como GitLab funciona para restaurar o serviço normal. Para mais informações, consulte a página de status do GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aaa7005ae52c614 "https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aaa7005ae52c614")

2. 13 Here 2026 da 08:47 UTCmonitoring

   O GitLab moveu o incidente afetando a conectividade de digitalização e integração de RP para a fase de monitoramento. O GitLab implementou uma correção e está monitorando os resultados. Continuamos a monitorar o impacto nas integrações do Cycode e forneceremos novas atualizações se necessário. Para mais informações, consulte a página de status do GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aaa7005ae52c614 "https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aaa7005ae52c614")

3. 13 Here 2026 da 11:27 UTCresolved

   O GitLab resolveu o incidente afetando a conectividade de digitalização e integração de RP

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 14:22 UTCinvestigating

   A equipe continua trabalhando com a AWS, que aumentou o problema internamente. Paralelamente, estamos trabalhando para restaurar a funcionalidade movendo-nos para outro banco de dados. Qualquer pedido de pull bloqueado à espera do status do Cycode pode ser desbloqueado removendo as varreduras do Cycode das verificações esperadas diretamente em seu SCM (Gestão de Código-Fonte). Fale com o seu representante Cycode para ajudar na racionalização do processo.

2. 7 Here 2026 da 14:22 UTCinvestigating

   AWS confirmou que a instância PostgreSQL afetada está atualmente em um estado de recuperação interna. O failover Multi-AZ esperado não ocorreu como projetado, e AWS está ativamente investigando o porquê. Paralelamente, continuamos a trabalhar para restaurar os serviços afetados usando um caminho de banco de dados alternativo para acelerar a recuperação

3. 7 Here 2026 da 14:22 UTCinvestigating

   Estamos a ver a base de dados a restaurar as suas capacidades operacionais. Vemos primeiro os exames do Pull Request a serem processados. Estamos monitorando o sistema e aumentando o rendimento.

4. 7 Here 2026 da 14:22 UTCinvestigating

   A base de dados continua totalmente operacional. Estamos trabalhando em aumentar a velocidade de processamento além do regular para processar todos os backlogs o mais rápido possível.

5. 7 Here 2026 da 14:22 UTCinvestigating

   Continuamos a investigar uma grande degradação na plataforma dos EUA causada pela exaustão da conexão PostgreSQL. Os clientes podem experimentar tempos de resposta lentos, elevados 500 erros e fluxos de trabalho de RP mais lentos e varreduras CLI. Reduzimos a carga do banco de dados em vários serviços e iniciamos uma falha no RDS. A equipe está trabalhando ativamente para restaurar o desempenho normal.

6. 7 Here 2026 da 14:22 UTCinvestigating

   Notamos desempenho degradado em prod-us Fluxos como Pull Request ou digitalização CLI podem ser mais lentos do que o normal

7. 7 Here 2026 da 14:22 UTCinvestigating

   A equipe está trabalhando ativamente com AWS e investigando o que parece ser um failover de banco de dados que afeta o ambiente dos EUA. Vamos compartilhar outra atualização assim que tivermos mais informações.

8. 7 Here 2026 da 14:22 UTCinvestigating

   A plataforma dos EUA está melhorando após a exaustão da conexão RDS/PostgreSQL anterior. AWS confirmou que a instância original do PostgreSQL retornou a um estado operacional, e estamos vendo as varreduras de RP sendo processadas novamente. A principal degradação restante é o processamento impulsionado pelo GitHub devido a um grande backlog webhook, que continua a drenar. Vamos continuar monitorando recuperação e fornecer outra atualização como processamento retorna ao normal

9. 7 Here 2026 da 14:22 UTCinvestigating

   O sistema está de volta a ser totalmente operacional

10. 7 Here 2026 da 14:22 UTCresolved

    (2/2) • Pausaram as cargas de trabalho que estavam criando altos volumes de operações de dados de curta duração, para reduzir a carga do banco de dados enquanto os eventos atrasados foram eliminados. • Escaneou os pedidos de pull que foram perdidos durante o incidente. **4b. Itens de Acção** • Alterar como grandes lotes de dados são escritos para reduzir a carga do banco de dados. • Mova nossa carga de trabalho de maior volume para seu próprio banco de dados dedicado, para que um problema não possa afetar o resto da plataforma. • Adicione alertas e monitoramento mais profundo para uso de conexão de banco de dados e saúde de banco de dados. • Dê a cada serviço as suas próprias credenciais de banco de dados. • Processar eventos recebidos de forma mais eficiente para acelerar a recuperação após uma interrupção. • Melhorar o acompanhamento dos atrasos de processamento e dos alertas de eventos internos. • Reveja a capacidade do banco de dados e as configurações de desempenho para adicionar mais headroom.

11. 7 Here 2026 da 14:22 UTCresolved

    (1/2) **1. Resumo Em 5 de outubro de 2026, a partir das 15:55 IDT, os clientes em nossa plataforma dos EUA viram respostas lentas, erros intermitentes e atrasos nas verificações de solicitação de puxar e varreduras CLI. Alguns clientes cujos repositórios requerem verificação de pedido de pull Cycode não puderam se fundir até a digitalização ser retomada. O problema começou quando um processo de manutenção de fundo em nosso banco de dados principal ficou para trás e parou de completar, e o banco de dados parou de salvar novos dados. O serviço de restauração levou várias horas porque o banco de dados de standby teve que processar um grande atraso de alterações. O banco de dados estava de volta e a plataforma estava novamente disponível por 19:43 TDI. O processamento atrasado então pegou, e o incidente foi resolvido em 23:24 IDT. Os pedidos de busca que foram perdidos durante o incidente foram digitalizados. **2. Linha temporal chave (IDT)** • ** 5 de Outubro de 2026, 12:55 IDT**: Um processo de manutenção de banco de dados de rotina começa a correr muito mais lentamente do que o normal. Nenhum impacto do cliente ainda. • ** 5 de Outubro de 2026, 14:53 IDT**: O próximo ciclo de manutenção começa e não termina. • ** 5 de Outubro de 2026, 15:55 IDT**: O banco de dados para de salvar novos dados e o desempenho da plataforma degrada. • ** 5 de Outubro de 2026, 16:03 IDT**: A base de dados atinge o seu limite de ligação. Os clientes começam a ver erros. • ** 5 de Outubro de 2026, 16:21 IDT**: Incidente declarado e equipa de resposta activada. • ** 5 de Outubro de 2026, 16:24 TDI**: Primeira atualização postada na página de status. • ** 5 de Outubro de 2026, 16:49 IDT**: Mudar para a base de dados de espera iniciada. • ** 5 de Outubro de 2026, 17:00 IDT**: Caso de suporte aberto com nosso provedor de infraestrutura na nuvem. • ** 5 de Outubro de 2026, 18:24 TDI**: Caminho de recuperação alternativo iniciado em paralelo. Solução publicada para clientes bloqueados por verificações de solicitação de pull necessárias. • ** 5 de Outubro de 2026, 19:43 DDT**: Banco de dados disponível novamente, e a API Cycode e a plataforma Cycode são acessíveis. • ** 5 de Outubro de 2026, 19:54 IDT**: Requisito de busca de currículos. • ** 5 de Outubro de 2026, 20:20 IDT**: A capacidade de processamento aumentou para esclarecer eventos atrasados. • ** 5 de Outubro de 2026, 20:45 IDT**: Cargas de trabalho de alto volume pausadas para reduzir a carga do banco de dados. • ** 5 de Outubro de 2026, 21:56 DDT**: Pedidos perdidos durante o incidente identificado e escaneado. • ** 5 de Outubro de 2026, 23:09 DDT**: Todos os serviços totalmente operacionais. • ** 5 de Outubro de 2026, 23:24 TDI**: Incidente resolvido. ** 3. Causa raiz** Nosso banco de dados executa um processo de fundo de rotina que regularmente salva alterações recentes para armazenamento permanente. Duas condições contribuíram para esse processo desacelerando: • ** Operações de dados de alto volume de curta duração:** algumas das nossas cargas de trabalho de processamento estavam constantemente criando e removendo grande número de estruturas de dados de curta duração. • **Uma sincronização de fundo atrasada:** um processo de sincronização de dados tinha caído muito atrás, o que impediu o banco de dados de limpar depois de si mesmo. O processo de manutenção abrandou e, eventualmente, parou de completar. O banco de dados não pôde mais salvar novos dados, e as solicitações começaram a filar. Nossos serviços testaram esses pedidos e abriram muitas novas conexões, que utilizaram a capacidade de conexão do banco de dados. Os clientes viram isso como erros e respostas lentas. Mudamos para a nossa base de dados. Antes que pudesse servir o tráfego, teve que processar todas as mudanças feitas desde o último ciclo de manutenção concluído, cerca de quatro horas de atividade. Isso estendeu a parada. **4. Acções tomadas** • Redução da carga no banco de dados, diminuindo temporariamente o processamento não essencial. • Iniciou uma mudança para o banco de dados standby. • Abriu um caso de suporte com nosso provedor de infraestrutura na nuvem e trabalhou com eles de forma crescente. • Preparar um caminho de recuperação alternativo em paralelo. • Partilhou uma solução temporária para os clientes bloqueados por verificações de solicitação de tração. • Uma vez recuperado o banco de dados, aumentou a capacidade de processamento para limpar eventos atrasados.

12. 7 Here 2026 da 14:22 UTCinvestigating

    O último atraso remanescente continua a ser processado a uma taxa constante. Nossas estimativas mostram que o último backlog de peças deve ser totalmente processado em cerca de 60-90 minutos (20:30 UTC). Vemos que a maioria dos exames de solicitação de tração (60% no momento desta atualização) estão sendo concluídos em menos de 15 minutos. e este número está crescendo constantemente a uma taxa constante. Além desse sistema, parece estar operacional. Acreditamos que a aplicação/UI está totalmente operacional.

Traduzido automaticamente da atualização oficial do incidente.

1. 5 Here 2026 da 13:24 UTCinvestigating

   Notamos desempenho degradado em prod-us Fluxos como Pull Request ou digitalização CLI podem ser mais lentos do que o normal

2. 5 Here 2026 da 14:17 UTCinvestigating

   Continuamos a investigar uma grande degradação na plataforma dos EUA causada pela exaustão da conexão PostgreSQL. Os clientes podem experimentar tempos de resposta lentos, elevados 500 erros e fluxos de trabalho de RP mais lentos e varreduras CLI. Reduzimos a carga do banco de dados em vários serviços e iniciamos uma falha no RDS. A equipe está trabalhando ativamente para restaurar o desempenho normal.

3. 5 Here 2026 da 14:29 UTCinvestigating

   A equipe está trabalhando ativamente com AWS e investigando o que parece ser um failover de banco de dados que afeta o ambiente dos EUA. Vamos compartilhar outra atualização assim que tivermos mais informações.

4. 5 Here 2026 da 15:17 UTCinvestigating

   A equipe continua trabalhando com a AWS, que aumentou o problema internamente. Paralelamente, estamos trabalhando para restaurar a funcionalidade movendo-nos para outro banco de dados. Qualquer pedido de pull bloqueado à espera do status do Cycode pode ser desbloqueado removendo as varreduras do Cycode das verificações esperadas diretamente em seu SCM (Gestão de Código-Fonte). Fale com o seu representante Cycode para ajudar na racionalização do processo.

5. 5 Here 2026 da 16:10 UTCinvestigating

   AWS confirmou que a instância PostgreSQL afetada está atualmente em um estado de recuperação interna. O failover Multi-AZ esperado não ocorreu como projetado, e AWS está ativamente investigando o porquê. Paralelamente, continuamos a trabalhar para restaurar os serviços afetados usando um caminho de banco de dados alternativo para acelerar a recuperação

6. 5 Here 2026 da 16:58 UTCinvestigating

   Estamos a ver a base de dados a restaurar as suas capacidades operacionais. Vemos primeiro os exames do Pull Request a serem processados. Estamos monitorando o sistema e aumentando o rendimento.

7. 5 Here 2026 da 17:31 UTCinvestigating

   A base de dados continua totalmente operacional. Estamos trabalhando em aumentar a velocidade de processamento além do regular para processar todos os backlogs o mais rápido possível.

8. 5 Here 2026 da 18:17 UTCinvestigating

   A plataforma dos EUA está melhorando após a exaustão da conexão RDS/PostgreSQL anterior. AWS confirmou que a instância original do PostgreSQL retornou a um estado operacional, e estamos vendo as varreduras de RP sendo processadas novamente. A principal degradação restante é o processamento impulsionado pelo GitHub devido a um grande backlog webhook, que continua a drenar. Vamos continuar monitorando recuperação e fornecer outra atualização como processamento retorna ao normal

9. 5 Here 2026 da 19:06 UTCinvestigating

   O último atraso remanescente continua a ser processado a uma taxa constante. Nossas estimativas mostram que o último backlog de peças deve ser totalmente processado em cerca de 60-90 minutos (20:30 UTC). Vemos que a maioria dos exames de solicitação de tração (60% no momento desta atualização) estão sendo concluídos em menos de 15 minutos. e este número está crescendo constantemente a uma taxa constante. Além desse sistema, parece estar operacional. Acreditamos que a aplicação/UI está totalmente operacional.

10. 5 Here 2026 da 20:09 UTCinvestigating

    O sistema está de volta a ser totalmente operacional

11. 5 Here 2026 da 20:24 UTCresolved

    **1. Resumo Em 5 de outubro de 2026, a partir das 15:55 IDT, os clientes em nossa plataforma dos EUA viram respostas lentas, erros intermitentes e atrasos nas verificações de solicitação de puxar e varreduras CLI. Alguns clientes cujos repositórios requerem verificação de pedido de pull Cycode não puderam se fundir até a digitalização ser retomada. O problema começou quando um processo de manutenção de fundo em nosso banco de dados principal ficou para trás e parou de completar, e o banco de dados parou de salvar novos dados. O serviço de restauração levou várias horas porque o banco de dados de standby teve que processar um grande atraso de alterações. O banco de dados estava de volta e a plataforma estava novamente disponível por 19:43 TDI. O processamento atrasado então pegou, e o incidente foi resolvido em 23:24 IDT. Os pedidos de busca que foram perdidos durante o incidente foram digitalizados. **2. Linha temporal chave (IDT)** • ** 5 de Outubro de 2026, 12:55 IDT**: Um processo de manutenção de banco de dados de rotina começa a correr muito mais lentamente do que o normal. Nenhum impacto do cliente ainda. • ** 5 de Outubro de 2026, 14:53 IDT**: O próximo ciclo de manutenção começa e não termina. • ** 5 de Outubro de 2026, 15:55 IDT**: O banco de dados para de salvar novos dados e o desempenho da plataforma degrada. • ** 5 de Outubro de 2026, 16:03 IDT**: A base de dados atinge o seu limite de ligação. Os clientes começam a ver erros. • ** 5 de Outubro de 2026, 16:21 IDT**: Incidente declarado e equipa de resposta activada. • ** 5 de Outubro de 2026, 16:24 TDI**: Primeira atualização postada na página de status. • ** 5 de Outubro de 2026, 16:49 IDT**: Mudar para a base de dados de espera iniciada. • ** 5 de Outubro de 2026, 17:00 IDT**: Caso de suporte aberto com nosso provedor de infraestrutura na nuvem. • ** 5 de Outubro de 2026, 18:24 TDI**: Caminho de recuperação alternativo iniciado em paralelo. Solução publicada para clientes bloqueados por verificações de solicitação de pull necessárias. • ** 5 de Outubro de 2026, 19:43 DDT**: Banco de dados disponível novamente, e a API Cycode e a plataforma Cycode são acessíveis. • ** 5 de Outubro de 2026, 19:54 IDT**: Requisito de busca de currículos. • ** 5 de Outubro de 2026, 20:20 IDT**: A capacidade de processamento aumentou para esclarecer eventos atrasados. • ** 5 de Outubro de 2026, 20:45 IDT**: Cargas de trabalho de alto volume pausadas para reduzir a carga do banco de dados. • ** 5 de Outubro de 2026, 21:56 DDT**: Pedidos perdidos durante o incidente identificado e escaneado. • ** 5 de Outubro de 2026, 23:09 DDT**: Todos os serviços totalmente operacionais. • ** 5 de Outubro de 2026, 23:24 TDI**: Incidente resolvido. ** 3. Causa raiz** Nosso banco de dados executa um processo de fundo de rotina que regularmente salva alterações recentes para armazenamento permanente. Duas condições contribuíram para esse processo desacelerando: • ** Operações de dados de alto volume de curta duração:** algumas das nossas cargas de trabalho de processamento estavam constantemente criando e removendo grande número de estruturas de dados de curta duração. • **Uma sincronização de fundo atrasada:** um processo de sincronização de dados tinha caído muito atrás, o que impediu o banco de dados de limpar depois de si mesmo. O processo de manutenção abrandou e, eventualmente, parou de completar. O banco de dados não pôde mais salvar novos dados, e as solicitações começaram a filar. Nossos serviços testaram esses pedidos e abriram muitas novas conexões, que utilizaram a capacidade de conexão do banco de dados. Os clientes viram isso como erros e respostas lentas. Mudamos para a nossa base de dados. Antes que pudesse servir o tráfego, teve que processar todas as mudanças feitas desde o último ciclo de manutenção concluído, cerca de quatro horas de atividade. Isso estendeu a parada. **4. Acções tomadas** • Redução da carga no banco de dados, diminuindo temporariamente o processamento não essencial. • Iniciou uma mudança para o banco de dados standby. • Abriu um caso de suporte com nosso provedor de infraestrutura na nuvem e trabalhou com eles de forma crescente. • Preparar um caminho de recuperação alternativo em paralelo. • Partilhou uma solução temporária para os clientes bloqueados por verificações de solicitação de tração. • Uma vez recuperado o banco de dados, aumentou a capacidade de processamento para limpar eventos atrasados. • Pausaram as cargas de trabalho que estavam criando altos volumes de operações de dados de curta duração, para reduzir a carga do banco de dados enquanto os eventos atrasados foram eliminados. • Escaneou os pedidos de pull que foram perdidos durante o incidente. **4b. Itens de Acção** • Alterar como grandes lotes de dados são escritos para reduzir a carga do banco de dados. • Mova nossa carga de trabalho de maior volume para seu próprio banco de dados dedicado, para que um problema não possa afetar o resto da plataforma. • Adicione alertas e monitoramento mais profundo para uso de conexão de banco de dados e saúde de banco de dados. • Dê a cada serviço as suas próprias credenciais de banco de dados. • Processar eventos recebidos de forma mais eficiente para acelerar a recuperação após uma interrupção. • Melhorar o acompanhamento dos atrasos de processamento e dos alertas de eventos internos. • Reveja a capacidade do banco de dados e as configurações de desempenho para adicionar mais headroom.

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 14:14 UTCmonitoring

   Às 14h00 EDT (18:00 UTC), identificamos um pico significativo de carga afetando o banco de dados de autenticação. Para mitigar o problema, realizamos uma atualização de instância. Uma breve interrupção nas conexões do banco de dados pode ter ocorrido durante a atualização. A plataforma é estável e continuamos a acompanhar de perto a situação.

2. 7 Here 2026 da 14:14 UTCresolved

   O sistema está totalmente operacional, sem problemas contínuos observados. Este incidente está agora resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 28 Gwengolo 2026 da 19:08 UTCmonitoring

   Às 14h00 EDT (18:00 UTC), identificamos um pico significativo de carga afetando o banco de dados de autenticação. Para mitigar o problema, realizamos uma atualização de instância. Uma breve interrupção nas conexões do banco de dados pode ter ocorrido durante a atualização. A plataforma é estável e continuamos a acompanhar de perto a situação.

2. 28 Gwengolo 2026 da 20:45 UTCresolved

   O sistema está totalmente operacional, sem problemas contínuos observados. Este incidente está agora resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 14:14 UTCresolved

   Resolvido

2. 7 Here 2026 da 14:14 UTCinvestigating

   Componente GitHub: Pedidos de Puxe Original incidente GitHub:

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Here 2026 da 08:42 UTCinvestigating

   Componente GitHub: Pedidos de Puxe Original incidente GitHub:

2. 8 Here 2026 da 08:42 UTCresolved

   Resolvido

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Gwengolo 2026 da 10:36 UTCinvestigating

   Componente GitHub: Pedidos de Puxe Original incidente GitHub:

2. 13 Gwengolo 2026 da 18:53 UTCresolved

   Resolvido

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 14:04 UTCresolved

   As métricas MemoryDB são estáveis, o lag de processamento se recuperou, e o sistema agora está totalmente operacional.

2. 7 Here 2026 da 14:04 UTCmonitoring

   Observamos um pico acentuado no uso da memória MemoryDB no prod-us, incluindo o uso ativo de swap. Foi aplicada a mitigação. MemoryDB métricas permaneceram estáveis desde então, e o atraso de processamento está diminuindo rapidamente

3. 7 Here 2026 da 14:04 UTCinvestigating

   Notamos desempenho degradado em prod-us Fluxos como Pull Request ou digitalização CLI podem ser mais lentos do que o normal

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Gwengolo 2026 da 16:53 UTCinvestigating

   Notamos desempenho degradado em prod-us Fluxos como Pull Request ou digitalização CLI podem ser mais lentos do que o normal

2. 8 Gwengolo 2026 da 17:21 UTCmonitoring

   Observamos um pico acentuado no uso da memória MemoryDB no prod-us, incluindo o uso ativo de swap. Foi aplicada a mitigação. MemoryDB métricas permaneceram estáveis desde então, e o atraso de processamento está diminuindo rapidamente

3. 8 Gwengolo 2026 da 17:26 UTCresolved

   As métricas MemoryDB são estáveis, o lag de processamento se recuperou, e o sistema agora está totalmente operacional.

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 14:14 UTCinvestigating

   Notamos desempenho degradado em prod-eu. A degradação do desempenho está afetando todas as aplicações e todos os fluxos (** como Pull Request ou CLI scan**) podem ser mais lentos do que o normal. Nossa investigação inicial sugere carga excessiva no banco de dados compartilhado, tornando a leitura e a escrita mais lentas. A equipa continua a investigar.

2. 7 Here 2026 da 14:14 UTCresolved

   O sistema voltou a ser totalmente operacional.

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Gwengolo 2026 da 09:53 UTCinvestigating

   Notamos desempenho degradado em prod-eu. A degradação do desempenho está afetando todas as aplicações e todos os fluxos (** como Pull Request ou CLI scan**) podem ser mais lentos do que o normal. Nossa investigação inicial sugere carga excessiva no banco de dados compartilhado, tornando a leitura e a escrita mais lentas. A equipa continua a investigar.

2. 8 Gwengolo 2026 da 10:52 UTCresolved

   O sistema voltou a ser totalmente operacional.

Traduzido automaticamente da atualização oficial do incidente.

1. 7 Here 2026 da 14:14 UTCresolved

   Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/0xbhhq84v4mt

2. 7 Here 2026 da 14:14 UTCinvestigating

   Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/0xbhhq84v4mt

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Here 2026 da 08:42 UTCinvestigating

   Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/0xbhhq84v4mt

2. 8 Here 2026 da 08:42 UTCresolved

   Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/0xbhhq84v4mt

Traduzido automaticamente da atualização oficial do incidente.

1. 1 Gwengolo 2026 da 15:10 UTCinvestigating

   Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/0xbhhq84v4mt

2. 1 Gwengolo 2026 da 16:05 UTCresolved

   Componente GitHub: Solicitações de Puxe Incidente original do GitHub: https://stspg.io/0xbhhq84v4mt

Traduzido automaticamente da atualização oficial do incidente.

1. 8 Here 2026 da 08:42 UTCinvestigating

   Componente GitHub: Solicitações de Puxe Incidente GitHub original: https://stspg.io/nrbwjftcz72d

2. 8 Here 2026 da 08:42 UTCresolved

   Componente GitHub: Solicitações de Puxe Incidente GitHub original: https://stspg.io/nrbwjftcz72d

Traduzido automaticamente da atualização oficial do incidente.