GitHub está enfrentando uma indisponibilidade no momento
(githubstatus.com)- Há uma degradação de desempenho em Pull Requests, e pode ser que nem todos os pull requests indexados apareçam nas páginas
/pullse/repo/pulls - No momento, o cluster Elasticsearch não contém todos os documentos indexados, mas os dados dos pull requests em si não foram perdidos e serão reindexados quando houver atualização
- Estão em andamento tanto o trabalho de reindexar os índices restantes quanto a aceleração de um full reindex para restaurar os resultados completos, priorizando a precisão e evitando impactos adicionais
- Na tabela de status dos componentes, apenas Pull Requests aparece em estado degradado; Git Operations, Webhooks, API Requests, Issues, Actions, Packages, Pages, Copilot, Codespaces e Copilot AI Model Providers estão em estado Operational
- No histórico recente, também estão publicados vários casos de indisponibilidade e ações de recuperação, como degradação da busca, falhas em jobs do Actions, falha ao iniciar sessões do agente do Copilot, regressão na merge queue, atrasos em Projects e falhas de conexão no Codespaces
Estado atual da indisponibilidade
- Há uma degradação de desempenho em Pull Requests, publicada no item Incomplete pull request results in repositories
- Nas páginas
/pullse/repo/pulls, pode ser que nem todos os pull requests indexados apareçam- No momento, o cluster Elasticsearch não contém todos os documentos indexados
- Os dados dos pull requests em si não foram perdidos
- Quando um pull request for atualizado, ele será reindexado
- A aceleração de um full reindex também está em andamento para restaurar os resultados completos
- Os índices restantes do Elasticsearch estão sendo reindexados, com prioridade para a precisão e evitando impactos adicionais
- Está sendo mantida uma abordagem cautelosa para fazer o backfill dos dados com segurança
Status dos componentes
- Na tabela de status atual, apenas Pull Requests aparece como
Degraded Performance - Os demais componentes principais estão em estado
Operational- Git Operations
- Webhooks
- API Requests
- Issues
- Actions
- Packages
- Pages
- Copilot
- Codespaces
- Copilot AI Model Providers
- O uptime dos últimos 90 dias também é fornecido
- Pull Requests 99.58% uptime
- API Requests 99.95% uptime
- Packages 99.97% uptime
- Copilot AI Model Providers 100.0% uptime
Página de status por região e canais de assinatura
- Há páginas de status separadas por região para o GitHub Enterprise Cloud
- Australia: au.githubstatus.com
- EU: eu.githubstatus.com
- Japan: jp.githubstatus.com
- US: us.githubstatus.com
- Também há canais para assinar alertas de status
- Slack: Subscribe via Slack
- Conta no X: @githubstatus
- Site de suporte: support site
- Feeds: Atom Feed, RSS Feed
Histórico recente de indisponibilidades
-
Apr 28 indisponibilidade em alguns serviços do GitHub
- O item Disruption with some GitHub services foi resolvido
- Houve atrasos no início e falhas em jobs hospedados em Ubuntu do Actions
- Parte das execuções
ubuntu-latesteubuntu-24.04atrasaram ou falharam - Em certo momento, cerca de 5% dos jobs foram afetados; depois caiu para menos de 2% e novamente para menos de 1%
- Parte das execuções
- O problema que bloqueava execuções do Actions foi mitigado e, por fim, o funcionamento normal foi restaurado
-
Apr 27 busca do GitHub degradada
- O item GitHub search is degraded foi resolvido
- Problemas de conexão com o Elasticsearch e carga adicional causaram falhas na busca e problemas em vários subserviços
- Issues, Pull Requests, Packages e Actions foram afetados
- Ocorreram falhas em workflow runs, falhas no carregamento de projects e timeout na busca
- Depois de bloquear a causa da carga adicional, surgiram sinais de recuperação, e em seguida o caso passou para monitoramento de estabilização
-
Apr 27 indisponibilidade em sessões do Copilot Cloud Agent Codex
- O item Disruption with some GitHub services foi resolvido
- Houve falha ao iniciar sessões do agente Codex no Copilot Cloud Agent
- O início não funcionava por nenhuma via, incluindo atribuição de issues e menções
@copilotem comentários - 0.5% de todos os trabalhos do Copilot Cloud Agent, cerca de 2.000 execuções com falha, foram afetados
- Outras sessões de agente do Copilot não foram afetadas
- O início não funcionava por nenhuma via, incluindo atribuição de issues e menções
- A causa foi um model resolution mismatch nas sessões do agente Codex, que fazia um modelo incompatível ser selecionado em runtime
- Foi aplicada uma mitigação para selecionar um modelo padrão estável para as sessões do agente Codex
Casos importantes com divulgação da causa raiz
-
Regressão na merge queue de Pull Requests
- Incident with Pull Requests foi resolvido
- Ao usar o modo squash merge na merge queue, se o merge group tivesse mais de um PR, era criado um merge commit incorreto
- Em merges posteriores, mudanças do PR anterior e mudanças do commit anterior podiam ser revertidas
- 2.092 pull requests foram afetados durante o período do problema
- PRs mesclados fora da merge queue e alguns grupos que usaram
mergeourebasenão foram afetados - A causa foi a aplicação de um novo caminho de código que ajustava o cálculo do merge base com feature flag gating incompleto
- A mudança de código foi revertida e um deploy forçado foi feito em todo o ambiente; os administradores dos repositórios afetados receberam procedimentos de recuperação separadamente
- Depois disso, o escopo dos testes de corretude de merge está sendo ampliado para incluir grupos squash com múltiplos PRs
-
Impossibilidade de iniciar agentes Claude e Codex pela web
- Disruption with users unable to start Claude and Codex agent task from the web foi resolvido
- Não era possível iniciar novas agent tasks com o agente Claude ou Codex no github.com
- A causa foi uma alteração no código de roteamento de task creation request do Copilot mission control
- Agent tasks em andamento e outras funcionalidades de agente do Copilot não foram afetadas
- A recuperação foi feita revertendo a alteração problemática, e estão sendo adicionados monitoramento extra e testes de integração ao caminho de criação de tasks
-
Falha no processamento de menções @ do Copilot
- Disruption with some GitHub services foi resolvido
- Menções
@copilotem comentários de pull request não resultavam na execução do Copilot coding agent- Entre todos os comentários de pull request e issue, cerca de 23.000 chamadas, equivalentes a 0.5% do total, não foram processadas
- A criação, visualização e resposta a comentários em si não foram afetadas
- A causa foi um serialization error que impediu a publicação de eventos para um downstream consumer
- Após o deploy da correção para restaurar a publicação de eventos, o processamento voltou ao normal, e estão em andamento revisão do schema de eventos relacionado e melhorias de monitoramento
-
Interrupção no Copilot Chat e Cloud Agent
- Disruption with Copilot chat and Copilot Coding Agent foi resolvido
- Houve erros no Copilot Chat e no Copilot Cloud Agent no github.com, e eles ficaram indisponíveis durante esse período
- O Copilot Memory em preview também não pôde ser usado nas sessões de agente
- A causa foi um problema de conexão com o banco de dados provocado por uma alteração de configuração de infraestrutura
- O github.com foi restaurado primeiro, e os deploys nas demais regiões foram recuperados em sequência
-
Atrasos no serviço Projects
- Disruption with projects service foi resolvido
- O Projects podia não sincronizar ou refletir mudanças com atraso
- O atraso na aplicação das mudanças chegou a cerca de 45 minutos no máximo
- A causa foi um serialization error que provocou falhas de eventos e aumento repentino de resync, sobrecarregando a camada de processamento de eventos
- A mitigação aumentou a velocidade de processamento das mudanças recebidas e, depois, a recuperação ocorreu com o consumo do backlog
-
Degradação na configuração padrão de code scanning e em Code Quality
- Partial degradation for code scanning default setup and for code quality foi resolvido
- Em novos pull requests, code scanning default setup e análises de code quality não eram acionados
- Também ocorreu um problema em que issues recém-criadas não apareciam no project board
- A causa foi um serialization error que impediu o acionamento correto de code scanning, análise de code quality e atualização do project board
- A publicação de eventos de code scanning e code quality foi restaurada, e a parte do project board foi recuperada com mudanças adicionais de código e reindex
- PRs que não foram processados antes ou durante o incidente precisam de um novo push para que a análise seja acionada novamente
Outros casos recentes de indisponibilidade
- Disruption with some GitHub services
- A experiência web do GitHub.com ficou degradada, e cerca de 1.5% das requisições web terminaram com erro
- Em alguns momentos, cerca de 10% do tráfego web ficou lento ou falhou
- A causa foi a saturação de capacidade de um componente de cache em uma região de datacenter
- A recuperação foi feita desviando o tráfego para regiões não afetadas e revertendo um deploy recente
- Incident with Codespaces
- Houve falha na conexão com o GitHub Codespaces pelo editor VS Code
- Cerca de 40% dos trabalhos de início de codespace falharam
- Conexões SSH não foram afetadas
- A causa foi uma indisponibilidade em um upstream download service que bloqueou o download do VS Code Server necessário na inicialização
- A mitigação usou uma rota alternativa de download quando o endpoint padrão estava degradado
- Disruption with some GitHub services
- O acesso à página Copilot Insights do GitHub Enterprise Cloud retornava erro 500
- Cerca de 709 usuários foram afetados, com tempo total de impacto de cerca de 5 horas e 10 minutos
- A causa foi falha de autenticação no metrics pipeline e mudança nas tenant credentials
- Estão em andamento melhorias em ferramentas de diagnóstico, monitoramento mais granular e reforço de alertas
1 comentários
Comentários do Hacker News
O pior agora é que também está falhando em silêncio
Por exemplo, mesmo com dezenas de PRs, aparece "There aren’t any open pull requests.", o que claramente induz as pessoas ao erro
Isso me atinge em cheio
Alguns meses atrás, o $PARENT_CONGLOMERATE forçou uma migração para o GitHub em toda a organização sob o argumento de sinergia e eficiência, e agora chegou a vez do $DAYJOB sair do GitLab self-hosted
Já tenho várias reclamações
A política de TI relacionada a contas do GH não faz o menor sentido: não podemos usar nenhuma conta existente, seja uma conta pessoal ou uma conta criada anteriormente separadamente para o $DAYJOB, então temos que criar outra conta nova que se encaixe nas regras de TI
Não usamos monorepo, então aproveitávamos bastante os groups, mas no GitHub não existe um equivalente direto, então temos que reorganizar manualmente os namespaces dos projetos
E agora ainda temos a disponibilidade do GitHub nesse estado
O cronograma de lançamento do nosso time é sensível à receita, então um atraso de um ou dois dias já pode decidir se vamos bater a meta mensal ou não
Em outra situação, eu teria espelhado antecipadamente o código crítico para a receita, mas não parece valer a pena assumir o risco para criar esse tipo de solução improvisada de guerrilha
Seria bom poder culpar o The Synergy Mandate no postmortem de um futuro próximo, mas eu também sei muito bem que isso não vai acontecer na prática
Só espero que a gente continue batendo as metas de receita e que o produto não seja cortado por desempenho ruim
Escrever isso me faz perceber ainda mais o quanto esse trabalho mudou desde quando entrei
Queria repetir isso para todos os projetos OSS
Sincronizar código entre vários forges com um job simples de CI é absurdamente fácil, e receber notificações por e-mail de um segundo forge quase não traz custo adicional
No mínimo, é preciso manter aberta a opção de contribuir fora do GitHub, e no fim isso é melhor para todo o ecossistema
Para a maioria dos projetos, talvez nem isso seja tão essencial
O difícil é tudo que fica em volta do código
tickets e PRs, incluindo o histórico dos já fechados
os vários links que referenciam o projeto
configuração de CI
em projetos grandes, a configuração das permissões de committer
se necessário, até todas as regras de push/commit/branch precisam ser migradas
essas coisas são um saco de migrar em cada projeto, e parte disso pode até se perder
Mas o problema maior é perder a plataforma principal para encontrar software
Fico pensando quando vai surgir um fediverse do software
O GitHub Actions ainda é a melhor opção, e nem a FSF nem outros labs OSS conseguiram oferecer CI decente para mantenedores de open source
Além disso, a carga de CI também ficou muito maior do que antes
Agora estou realmente achando que temos que pressionar alternativas
Isso começou a ter impacto real no nosso negócio, e não há absolutamente nenhum sinal de melhora
Só vai ter que aceitar a limitação da estrutura org/repo
Se quiser algo parecido, mas com uma experiência um pouco diferente, GitLab é a escolha certa
Se você prefere algo mais próximo do mundo kernel — isto é, hospedagem e estrutura de repositório flexíveis, autenticação de usuário baseada em ssh key e uma interface web simples — então pode usar gitolite com cgit ou gitweb
Tanto Gitea quanto Forgejo são suficientes, desde que os recursos oferecidos atendam ao que você precisa
Às vezes eu passo em threads sobre falhas do GitHub para dar risada, porque a nossa instância de Gitea teve no total só alguns minutos de downtime nos últimos anos, e tudo foi por upgrades planejados no meio da noite
Não é uma cópia completa, mas é suficientemente próximo; eu diria que a diferença é mais de maçã para pera do que de laranja para maçã
Só que o GitHub realmente é uma plataforma pegajosa; depois que você instala actions e todo tipo de integração, fica difícil sair
Mesmo assim, a frequência dessas falhas já está num nível meio absurdo
Parece não ser algo exclusivo do GitHub, e sim uma falha maior: https://downdetector.com
Mais um fim de dia com a letra y no nome, então isso só pode significar falha no GitHub de novo
Codeberg.org também está com problemas agora
https://status.codeberg.org/status/codeberg
https://social.anoxinon.de/@codebergstatus/11647770704799298...
Se você não gosta quando o GitHub cai, e também não gosta de IA roubando código, talvez valha a pena usar o sourcehut
Para mim funcionou muito bem, e eu gostaria que ele prosperasse mais como plataforma
No fim, isso não é só mais um serviço centralizado?
Dessa vez está demorando especialmente muito
Fico pensando numa piada do tipo: o time encarregado do conserto bateu no limite de sessão do Claude e não consegue mexer em nada até acabar o cooldown, e a única pessoa que sabe consertar sem IA está fora fazendo cirurgia
Também me pergunto o que vai acontecer quando toda a geração que sabia consertar as coisas sem IA se aposentar
Cada vez que o GitHub cai, mais algumas pessoas migram para alternativas éticas, e a estrutura em que a comunidade FOSS mantém um SPOF na Microsoft também enfraquece um pouco
https://sfconservancy.org/GiveUpGitHub/
Era fácil colaborar, e agora, por vários motivos, o atrito está aumentando
issues estão sendo usados cada vez mais como spam, e também começam a aparecer atividades ainda mais maliciosas