- Foram relatadas degradação de desempenho e erros em serviços principais do GitHub, como Actions, Issues e operações Git
- O escopo do impacto se expandiu para Webhooks, Pull Requests, Packages, Pages e Codespaces
- O GitHub aplicou medidas de mitigação e confirmou uma recuperação gradual; depois disso, todos os serviços foram normalizados
- A falha também afetou alguns serviços como Dependabot e Copilot, mas no fim todos voltaram ao estado operacional normal
- O GitHub pretende divulgar posteriormente a análise de causa raiz (RCA) e agradeceu aos usuários pela paciência e cooperação
Visão geral da falha
- O GitHub anunciou que estava investigando relatos de degradação de desempenho em Actions, operações Git e Issues
- Na fase inicial, foram observados respostas lentas e requisições com falha, além de tarefas do Actions atrasadas
- A falha foi relatada pela primeira vez em 9 de fevereiro de 2026, às 19:01 UTC
Serviços afetados
- Os componentes afetados foram operações Git, Webhooks, Issues, Pull Requests, Actions, Packages, Pages e Codespaces
- Depois, também foram confirmados problemas em Dependabot e Copilot
- Cada serviço foi marcado com o status de “degraded performance” (desempenho degradado)
Resposta e processo de recuperação
- O GitHub informou que observou sinais de recuperação após aplicar medidas de mitigação
- A recuperação gradual começou após 19:29 UTC
- Às 19:54 UTC, vários serviços já haviam se recuperado, embora alguns ainda estivessem sob investigação
- Às 20:08 UTC, foi informado que “todos os serviços estavam operando normalmente”
- Às 20:09 UTC, o status foi alterado para falha resolvida (Resolved)
Estado final e ações posteriores
- O GitHub declarou que todos os serviços voltaram ao estado operacional normal
- Actions, Codespaces, operações Git, Issues, Packages, Pages, Pull Requests e Webhooks foram todos normalizados
- A análise de causa raiz (Root Cause Analysis) será compartilhada assim que estiver pronta
- A empresa agradeceu aos usuários pela paciência e compreensão
Resumo
- Esta falha afetou grande parte do fluxo de trabalho central de desenvolvimento no GitHub
- Após a conclusão da recuperação, a RCA será divulgada, e são esperadas melhorias para evitar falhas semelhantes no futuro
- O fato de outra falha ter sido relatada na mesma data destaca a importância da gestão da estabilidade
1 comentários
Comentários do Hacker News
Por causa das falhas parciais contínuas do GitHub, estou considerando migrar a empresa inteira para outro fornecedor
Recursos que antes funcionavam bem agora estão lentos, e o Actions também não roda no tempo certo
O Copilot é legal, mas no fim, se a git forge não funciona direito, não tem como ficar
Até abrir um diff simples de PR leva mais de 15 segundos, e a UI parece travar repetidamente
É surpreendente como essa degradação anormal de desempenho está sendo aceita como algo normal
No fim, poder rodar pipelines de CI localmente também faz parte da essência do git
Eu uso o GH apenas para sincronização
Pelos textos antigos, eles já estavam batendo no limite de escalabilidade do banco SQL
É parecido com o caso de escala do Postgres da OpenAI, mas o GitHub parece não ter lidado tão bem com isso
As falhas frequentes do GitHub acabam servindo como oportunidade para testar a resiliência do pipeline de deploy
A maioria dos times depende totalmente do GitHub, então quando ele cai, o deploy para
Por isso, estão tentando alternativas como estas
A página oficial de status sempre é atualizada com atraso, então agora é tratada apenas como informação “eventually consistent”
Pode ser que o GitHub esteja sofrendo com a carga causada pela explosão de workflows de desenvolvimento automatizados
Os commits em repositórios pessoais aumentaram de forma explosiva, mas quase não houve conversão para plano pago
Em 2019, ao tornar repositórios privados gratuitos, eles teriam perdido a chance de monetização
E também faltaria senso de responsabilidade em relação ao downtime
Defendem que o GitLab é a alternativa
O GitHub agora estaria focado apenas em uma estratégia centrada em IA, deixando a própria plataforma em segundo plano
A adoção do Copilot também seria baixa, e as empresas estariam usando mais o Claude
Se a Microsoft mudar de direção, a situação pode piorar ainda mais
Recursos são lançados em estado meio inacabado, e a velocidade também é lenta
As vantagens do modelo open core já não parecem tão claras
Evoluiu de Dev → DevOps → DevSecOps → AI DevSecOps, mas
em cada etapa a conclusão ficou aquém, e a necessidade de upgrade de licença é incômoda
Consideram que o próprio modelo de juntar CI/CD e hospedagem de código é o problema
Mesmo funcionando perfeitamente, no fim é impossível evitar o lock-in de fornecedor
Antes bastava trocar o remote, mas agora tudo ficou amarrado com PR, wiki etc.
Agora as falhas do GitHub já parecem não ser apenas um problema de SaaS, mas uma falha em nível de nuvem
Por isso, muitos times estão migrando para GitLab/Gitea auto-hospedados
Em uma grande empresa, por motivos de segurança, usavam GitLab Enterprise on-premises, e
em projetos pessoais, usam Forgejo
Git, issues, boards e wiki funcionam bem, e labels com escopo são gratuitas
Existe uma página que visualiza o histórico de múltiplas falhas do GitHub
Dá para conferir em mrshu.github.io/github-statuses
Há também um comentário em tom de piada: “time do GitHub, podem ir devagar”
Há quem queira sair do GitHub, mas precise de CI estável e registro de contêineres
Se houver uma solução que “simplesmente funcione”, estaria disposto a pagar
É adequado para workloads grandes, mas o custo inicial é alto
O gerenciamento de permissões do registro é um pouco complexo, mas a integração geral é boa
Acham que deveríamos voltar a ferramentas de propósito único, como na filosofia Unix
Seria interessante ver um gráfico da correlação entre taxa de adoção de IA e frequência de falhas